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为 什么 要 与 这 本 市 


记得 第 一 次 写 并 发 编程 的 文章 时 还 是 在 2012 年 ， 当 时 花 了 几 个 星期 
的 时 间 写 了 一 篇 文章 《深入 分 析 volatile 的 实现 原理 》， 准 备 在 自己 的 博 
客 中 发 表 。 在 同事 建 法 的 建议 下 ， 怀 着 试 一 试 的 心态 投向 了 InfoQ， 庆 
幸 的 是 半 小 时 后 得 到 InfoQ 主 编 采 纳 的 回复 ， 高 兴 之 情 无 以 言 表 。 这 也 
是 我 第 一 次 在 专业 媒体 上 发 表 文 章 ， 而 后 在 InfoQ 编 辑 张 龙 的 不 断 鼓励 
和 支持 下 ， 我 陆续 在 InfoQ 发 表 了 几 篇 与 并 发 编程 相关 的 文章 ， 于 是 便 
形成 了 “ 聊 聊 并 发 ”专栏 。 在 这 个 专栏 的 写作 过 程 中 ， 我 得 到 快速 的 成 
长 和 非常 多 的 帮助 ， 在 此 非常 感谢 InfoQ 的 编辑 们 。2013 年 ， 华 章 的 福 
川 兄 找到 我 ， 问 有 没有 兴趣 写 一 本 书 ， 当 时 觉得 自己 资历 尚 浅 ， 婉 言 拒 
绝 了 。 后 来 和 福 川 兄 一 直 保持 联系 ， 最 后 允许 我 花 两 年 的 时 间 来 完成 本 
书 ， 所 以 答应 了 下 来 。 由 于 并 发 编程 领域 的 技术 点 非常 多 且 深 ， 所 以 陆 
续 又 邀请 了 同事 魏 胸 和 朋友 了 晓 明 一 起 参与 到 本 书 的 编写 当中 。 


写本 书 的 过 程 也 是 对 自己 研究 和 掌握 的 技术 点 进行 整理 的 过 程 ， 布 
望 本 书 能 帮助 读者 快速 掌握 并 发 编程 技术 。 


本 书 一 共 11 章 ， 由 三 名 作者 共同 编写 完成 ， 其 中 第 3 章 和 第 10 章 节 
由 程 晓 明 编写 ， 第 4 章 和 第 5 章 由 魏 鹏 编写 ， 其 他 7 章 由 方腊 飞 编写 。 


本 书 特色 
本 书 结合 JDK 的 源码 介绍 了 Java 并 发 框架 、 线 程 池 的 实现 原理 ， 帮 
助 读者 做 到 知 其 所 以 然 。 


本 书 对 原理 的 剖析 不 仅仅 局 限于 Java 层 面 ， 而 是 深入 到 JVM， 甚 至 
CPU 层面 来 进行 讲解 ， 帮 助 读 者 从 更 底层 看 并 发 技术 。 


本 书 结合 线 上 应 用 ， 给 出 了 一 些 并 发 编程 实战 技巧 ， 以 及 线 上 处 理 


并 发 问题 的 步骤 和 思路 。 


读者 对 象 


Java 开发 工程 师 


` 架构 师 


. 并 发 编程 爱好 者 


: 开设 相关 课程 的 大 专 院 校 师 生 


如 何 阅 读本 书 


阅读 本 书 之 前 ， 你 必须 有 一 定 的 Java 基 础 和 开发 经 验 ， 最 好 还 有 一 


定 的 并 发 编程 基础 。 如 果 你 是 一 名 并 发 编程 初学 者 ， 建 议 按照 顺序 阅读 
本 书 ， 并 按照 书 中 的 例子 进行 编码 和 实战 。 如 果 你 有 一 定 的 并 发 编程 经 
验 ， 可 以 把 本 书 当 做 一 个 手册 ， 直 接 看 需要 学 习 的 章节 。 以 下 是 各 章节 
的 基本 介绍 。 


第 1 章 介绍 Java 并 发 编程 的 挑战 ， 向 读者 说 明 进 入 并 发 编程 的 世界 
可 能 会 遇 到 哪些 问题 ， 以 及 如 何 解 决 。 


第 2 章 介绍 Java 并 发 编程 的 底层 实现 原理 ， 介 绍 在 CPU 和 JVM 这 个 层 


面 是 如 何 帮 助 Java 实 现 并 发 编程 的 。 


第 3 章 介绍 深入 介绍 了 Java 的 内 存 模型 。Java 线 程 之 间 的 通信 对 程序 
员 完 全 透明 ， 内 存 可 见 性 问题 很 容易 困扰 Java 程 序 员 ， 本 章 试图 揭 开 
Java 内 存 模型 的 神秘 面纱 。 


第 4 音 从 介绍 多 线程 技术 带 来 的 好 处 开始 ， 讲 述 了 如 何 启 动 和 终止 
线程 以 及 线程 的 状态 ， 详 细 阅 述 了 多 线程 之 间 进 行 通信 的 基本 方式 和 等 


待 /i 通知 经 典范 式 。 


第 5 章 介绍 Java 并 发 包 中 与 锁 相 关 的 API 和 组 件 ， 以 及 这 些 API 和 组 
件 的 使 用 方式 与 实现 细节 。 


第 6 章 介绍 了 Java 中 的 大 部 分 并 发 容器 ， 并 深入 剖析 其 实现 原理 ， 
让 读者 领略 大 师 的 设计 技巧 。 


第 7 章 介绍 了 Java 中 的 原子 操作 类 ， 并 给 出 一 些 实例 。 


第 8 章 介绍 了 Java 中 提供 的 并 发 工具 类 ， 这 是 并 发 编程 中 的 瑞士 军 


第 10 章 介绍 了 Executor 框 架 的 整体 结构 和 成 员 组件 。 


第 11 章 介绍 几 个 并 发 编程 的 实战 ， 以 及 排查 并 发 编程 造成 问题 的 


方法 。 


勘误 和 支持 


由 于 笔者 的 水 平 有 限 ， 编 写 时 间 仓 促 ， 书 中 难免 会 出 现 一 些 错误 或 
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第 1 章 ” 并 及 纺 程 的 挑战 








并 发 编程 的 目的 是 为 了 让 程序 运行 得 更 快 ， 但 是 ， 并 不 是 局 动 更 多 
的 线程 束 能 让 程序 最 大 限度 地 并 发 执行 。 在 进行 并 发 编程 时 ， 如 来 希望 
通过 多 线程 执行 任务 让 程序 运行 得 更 快 ， 会 面临 非常 多 的 挑战 ， 比 如 上 
下 文 切换 的 问题 、 死 锁 的 问题 ， 以 及 受 限 于 硬件 和 软件 的 资源 限制 问 
题 ， 本 革 会 介绍 几 种 并 发 编程 的 挑战 以 及 解决 方案 。 





1.1 上 下 文 切换 


即使 是 单 核 处 理 器 也 支持 多 线程 执行 代码 ，CPU 通 过 给 每 个 线程 分 
配 CPU 时 间 扩 来 实现 这 个 机 制 。 时 间 卢 是 CPU 分 配给 各 个 线程 的 时 间 ， 
因为 时 间 片 非常 短 ， 所 以 CPU 通过 不 停 地 切换 线程 执行 ， 让 我 们 感觉 
个 线程 是 同时 执行 的 ， 时 间 片 一 般 是 几 十 毫秒 (ms) 。 


CPU 通过 时 间 广 分配 算法 来 循环 执行 任务 ， 当 前 任务 执行 一 个 时 间 
片 后 会 切换 到 下 一 个 任务 。 但 是 ， 在 切换 前 会 保存 上 一 个 任务 的 状态 ， 
以 便 下 次 切换 回 这 个 任务 时 ， 可 以 再 加 载 这 个 任务 的 状态 。 所 以 任务 从 
保存 到 再 加 载 的 过 程 就 是 一 次 上 下 文 切换 。 


这 就 像 我 们 同时 读 两 本 书 ， 当 我 们 在 读 一 本 英文 的 技术 书 时 ， 发 现 
某 个 单词 不 认识 ， 于 是 便 打 开 中 英文 字典 ， 但 是 在 放下 英文 技术 书 之 
前 ， 大 脑 必须 先 记 住 这 本 书 该 到 了 多 少 页 的 第 多 少 行 ， 等 得 完 单 词 之 
后 ， 能 够 继续 读 这 本 书 。 这 样 的 切换 是 会 影响 读书 效率 的 ， 同 样 上 下 文 
切换 也 会 影响 多 线程 的 执行 速度 。 





1.1.1 多 线程 一 定 快 吗 


下 面 的 代码 演示 串 行 和 并 发 执行 并 累加 操作 的 时 间 ， 请 分 析 : 下 面 
的 代码 并 发 执行 一 定 比 串 行 执行 快 吗 ? 





public class ConcurrencyTest { 
private static final long count = 100001; 
public static void main(String[] args) throws InterruptedException { 
concurrency(); 
serial(); 
} 
private static void concurrency() throws InterruptedException { 
long start = System.currentTimeMillis(); 
Thread thread = new Thread(new Runnable() { 
Q@Override 
public void run() { 
int a = 0; 
for (long i = 0; i < count; i++) { 


a += 5; 
} 

} 
}); 
thread,. start(); 
int b = 0; 
for (long i = 0; i < count; i++) { 

b--; 
} 


long time = System,currentTimeMillis() - start,; 

thread.join( ); 

System.out.printin("concurrency :" + time+"ms,b="+b); 
} 
private static void serial() { 

long start = System.currentTimeMillis(); 

int a = 0; 

for (long i = 0; i < count; i++) { 


a += 5) 

} 

int b = 0; 

for (long i = 0; i < count; i++) { 
b--; 

} 


long time = System,currentTimeMillis() - start,; 
System.out.printin("serial:" + time+"ms,b="+b+",a="+a); 





上 述 问 题 的 答 采 是 “不 一 定 ”， 测试 结果 如 表 1-1 所 示 。 


表 1-1 测试 结果 
循环 次 数 串 行 执行 耗 时 /ms 并 发 执行 耗 时 并 发 比 串 行 快 多 少 


[人 m7 | 和 

iT， | 人 

FE | 
天 el 
EC ll 

从 表 1-1 可 以 发 现 ， 当 并 发 执行 累加 操作 不 超过 百 万 次 时 ， 速 度 会 

比 串 行 执行 累加 操作 要 慢 。 那 么 ， 为 什么 并 发 执行 的 速度 会 比 品行 慢 


呢 ? 这 是 因为 线程 有 创建 和 上 下 文 切 换 的 开销 。 


有 





1.1.2 测试 上 下 文 切换 次 数 和 时 长 





下 面 我 们 来 看 看 有 什么 工具 可 以 度量 上 下 文 切换 带 来 的 消耗 。 
. 使 用 Lmbench31 可 以 测量 上 下 文 切 换 的 时 长 。 
' 使 用 vmstat 可 以 测量 上 下 文 切换 的 次 数 。 


下 面 是 利用 vmstat 测 量 上 下 文 切 换 次 数 的 示例 。 





$ vmstat 1 
procs ----------- memory---------- --- SWap-- ----- i0---- -- System-- ----- cpu----- 
r b Swpd free buff cache si S i bo in cs us sy id wa st 
4 2 2 0 099 0 0 


1 
© 127876 398928 2297092 0 0 
0 © 595 1171 0 199 0 0 
0 
0 


© 127868 398928 2297092 0 
© 127868 398928 2297092 0 
0 127868 398928 2297092 0 


© 590 1180 1 0 100 0 0 
© 567 1135 0 199 0 0 





CS (Content Switch〉 表 示 上 下 文 切换 的 次 数 ， 从 上 面 的 测试 结 
中 我 们 可 以 看 到 ， 上 下 文 每 1 秒 切 换 1000 多 次 。 


[1] Lmbench3 是 一 个 性 能 分 析 工 具 。 


1.1.3 如何 减 少 上 下 文 切换 


减少 上 下 文 切 换 的 方法 有 无 锁 并 发 编程 、CAS 算 法 、 使 用 最 少 线程 
和 使 用 协 程 。 


无 锁 并 发 编程 。 多 线程 竞争 锁 时 ， 会 引起 上 下 文 切 换 ， 所 以 多 线 
程 处 理 数据 时 ， 可 以 用 一 些 办 法 来 避免 使 用 锁 ， 如 将 数据 的 ID 按照 Hash 
算法 取 模 分 段 ， 不 同 的 线程 处 理 不 同 段 的 数据 。 


. CAS 算 法 。Java 的 Atomic 包 使 用 CAS 算 法 来 更 新 数据 ， 而 不 需要 加 
锁 。 
` 使 用 最 少 线 程 。 避 免 创 建 不 需要 的 线程 ， 比 如 任务 很 少 ， 但 是 创 


建 了 很 多 线程 来 处 理 ， 这 样 会 造成 大 量 线程 都 处 于 等 待 状态 。 


协 程 : 在 单线 程 里 实现 多 任务 的 调度 ， 并 在 单线 程 里 维持 多 个 任 
务 间 的 切换 。 


1.1.4 减少 上 下 文 切换 实战 


本 节 将 通过 减少 线 上 大 量 WAITING 的 线程 ， 来 减少 上 下 文 切换 次 
数 。 





第 一 步 : 用 jstack 命 令 dump 线 程 信息 ， 看 看 pid 为 3117 的 进程 里 的 线 
程 都 在 做 什么 





sudo -u admin /opt/ifeve/java/bin/jstack 31177 > /home/tengfei.fangtf/dump17 





第 二 步 : 统计 所 有 线程 分 别处 于 什么 状态 ， 发 现 300 多 个 线程 处 于 
WAITING 〈onobject-monitor) 状态 。 





[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.state dump17 | awk '{print $2$3$4$5] 
| sort | uniq -c 

39 RUNNABLE 

21 TIMED_WAITING(onobjectmonitor) 

6 TIMED_WAITING(parking) 

51 TIMED_ WAITING(sleeping) 

305 WAITING(onobjectmonitor) 

3 WAITING(parking) 





第 三 步 : 打开 dump 文 件 查看 处 于 WAITING (onobjectmonitor) 的 
线程 在 做 什么 。 发 现 这 些 线程 基本 全 是 JBOSS 的 工作 线程 ， 在 await。 说 
明 JBOSS 线 程 池 里 线程 接收 到 的 任务 太 少 ， 大 量 线程 都 闲 着 。 








"http-0.0.0.0-7001-97" daemon prio=10 tid=0x000000004f6a8000 nid=0x555e in 
Object.wait() [9x9000000052423000] 

java.lang.Thread.State: WAITING (on object monitor ) 

at java.lang.Object.wait(Native Method ) 


- waiting on <0x00000007969b2280> (a org.apache.tomcat.util.net.AprEndpoint$Wworker, 
at java.lang.Object.wait(Object.java:485) 

at org.apache.tomcat.util.net.AprEndpoint$worker .await(AprEndpoint .java:1464) 

- locked <0x00000007969b2280> (a org.apache.tomcat.util.net.AprEndpoint$worker) 

at org,.apache,.tomcat,util,net,AprEndpoint$worker ,run(AprEndpoint ,java:1489 ) 

at java.lang.Thread.run(Thread.java:662) 





第 四 步 : 减少 JBOSS 的 工作 线程 数 ， 找 到 JBOSS 的 线程 池 配 置信 
息 ， 将 maxThreads 降 到 100。 





<maxThreads="250" maxHttpHeaderSize="8192" 
emptySessionPath="false" minSpareThreads="40" maxSpareThreads="75" 
maxPostSize="512000" protocol="HTTP/1.1" 
enableLookups="false" redirectPort="8443" acceptCount="200" bufferSize="16384" 
connectionTimeout="15000" disableUploadTimeout="false" useBodyEncodingForURI= "true 





第 五 步 : 重启 JBOSS， 再 dump 线 程 信息 ， 然 后 统计 
WAITING 〈onobjectmonitor) 的 线程 ， 发 现 减少 了 175 个 。WAITING 的 
线程 少 了 ， 系 统 上 下 文 切 换 的 次 数 就 会 少 ， 因 为 每 一 次 从 WAITTING 到 
RUNNABLE 都 会 进行 一 次 上 下 文 的 切换 。 读 者 也 可 以 使 用 vmstat 命 令 测 
Lr 





[tengfei.fangtf@ifeve ~]$ grep java.lang.Thread.Sstate dump17 | awk '{print $2$3$4$5] 
| sort | uniq -c 
44 RUNNABLE 
22 TIMED_WAITING(onobjectmonitor) 
9 TIMED_WAITING(parking) 
36 TIMED_WAITING(sleeping) 
130 WAITING(onobjectmonitor) 
1 WAITING(parking) 


ee | 


1.2 ”和 死 锁 


锁 是 个 非常 有 用 的 工具 ， 运 用 场景 非常 多 ， 因 为 它 使 用 起 来 非常 简 
单 ， 而 且 易 于 理解 。 但 同时 它 也 会 带 来 一 些 困 扰 ， 那 束 是 可 能 会 引起 死 
锁 ， 一 旦 产生 死 锁 ， 就 会 造成 系统 功能 不 可 用 。 让 我 们 先 来 看 一 段 代 
码 ， 这 段 代 码 会 引起 死 锁 ， 使 线程 tL 和 线程 忆 互 相等 待 对 方 释放 锁 。 





public class DeadLockDemo { 
privat static String A = "A"; 
private static String B = "B"; 
public static void main(String[] args) { 
new DeadLockDemo().deadLock( ); 


private void deadLock() { 
Thread t1 = new Thread(new Runnable() { 
Q@Override 
publicvoid run() { 
synchronized (A) { 
try { Thread.currentThread().sleep(2000); 
} catch (InterruptedException e) { 
e.printSstackTrace(); 


} 
synchronized (B) { 
System,.out.printlin("1"); 


} 
} 
} 
}); 
Thread t2 = new Thread(new Runnable() { 
Q@Override 


publicvoid run() { 
synchronized (B) { 
synchronized (A) { 
System,.out.printlin("2"); 


} 
} 


}); 
ti.start(); 
t2.start(); 





这 段 代码 只 是 演示 死 锁 的 场景 ， 在 现实 中 你 可 能 不 会 写 出 这 样 的 代 
码 。 但 是 ， 在 一 些 更 为 复杂 的 场景 中 ， 你 可 能 会 遇 到 这 样 的 问题 ， 比 如 
t 拿 到 锁 之 后 ， 因 为 一 些 异常 情况 没有 释放 锁 〈 死 循环 ) 。 又 或 者 是 t1 
拿 到 一 个 数据 库 锁 ， 释 放 锁 的 时 候 抛 出 了 异常 ， 没 释放 挥 。 


一 旦 出 现 死 锁 ， 业 务 是 可 感知 的 ， 因 为 不 能 继续 提供 服务 了 ， 那 么 
只 能 通过 dump 线 程 查 看 到 底 是 哪个 线程 出 现 了 问题 ， 以 下 线程 信息 告 
诉 我 们 是 DeadLockDemo 类 的 第 42 行 和 第 31 行 引起 的 死 锁 。 





"Thread-2" prio=5 tid=7fc0458d1000 nid=0x116c1c000 waiting for monitor entry [116ci1t 
java.1lang.Thread.State: BLOCKED (on object monitor) 
at com.ifeve.book.forkjoin.DeadLockDemo$2.run(DeadLockDemo.java:42) 
- waiting to lock <7fb2f3ec0> (a java.lang.string) 
- locked <7fb2f3ef8> (a java.lang.String) 
at java.lang.Thread.run(Thread.java:695) 
"Thread-1" prio=5 tid=7fc0430f6800 nid=0x116b19000 waiting for monitor entry [116b1:t 
java,lLang,Thread.State: BLOCKED (on object monitor) 
at com.ifeve.book.forkjoin.DeadLockDemo$1.run(DeadLockDemo.java:31) 
- waiting to lock <7fb2f3ef8> (a java.lang,String) 
- locked <7fb2f3ec0> (a java.lang.String) 
at java.lang.Thread.run(Thread.java:695) 





现在 我 们 介绍 避免 死 锁 的 几 个 常见 方法 。 
` 避免 一 个 线程 同时 获取 多 个 锁 。 


` 避免 一 个 线程 在 锁 内 同时 占用 多 个 资源 ， 尽 量 保证 每 个 锁 只 占用 


一 个 资源 。 


` 尝试 使 用 定时 锁 ， 使 用 lock.tryLock (timeout) 来 替代 使 用 内 部 锁 
机 制 。 


对 于 数据 库 锁 ， 加 锁 和 解锁 必须 在 一 个 数据 库 连 接 里 ， 否 则 会 出 
现 解 锁 失 败 的 情况 。 


1.3 资源 限制 的 挑 成 


(1) 什么 是 资源 限制 





资源 限制 是 指 在 进行 并 发 编程 时 ， 程 序 的 执行 速度 受 限 于 计算 机 人 硬 
件 资源 或 软件 资源 。 例 如 ， 服 务 器 的 市 宽 只 有 2Mb/s， 某 个 资源 的 下 载 
速度 是 1Mb/s 每 秒 ， 系 统 局 动 10 个 线程 下 载 资源 ， 下 载 速 度 不 会 变 成 
10Mb/s， 所 以 在 进行 并 发 编程 时 ， 要 考虑 这 些 资 源 的 限制 。 硬 件 资源 限 
制 有 带宽 的 上 传 / 下 载 速度 、 硬 盘 读 写 速 度 和 CPU 的 处 理 速度 。 软 件 资 
源 限制 有 数据 库 的 连接 数 和 socket 连 接 数 等 。 


(2) 资源 限制 引发 的 问题 


在 并 发 编程 中 ， 将 代码 执行 速度 加 快 的 原则 是 将 代码 中 串 行 执行 的 
部 分 变 成 并 发 执行 ， 但 是 如 果 将 茶 段 串 行 的 代码 并 发 执行 ， 因 为 受 限于 
资源 ， 仍 然 在 单行 执行 ， 这 时 候 程序 不 仅 不 会 加 快 执行 ， 反 而 会 更 慢 ， 
因为 增加 了 上 下 文 切 换 和 资源 调度 的 时 间 。 例 如 ， 之 前 看 到 一 段 程序 使 
用 多 线程 在 办 公 网 并 发 地 下 载 和 处 理 数据 时 ， 导 致 CPU 利用 率 达 到 
100%， 几 个 小 时 都 不 能 运行 完成 任务 ， 后 来 修改 成 单线 程 ， 一 个 小 时 
就 执行 完成 了 。 





(3) 如 何 解决 资源 限制 的 问题 


对 于 人 硬件 资源 限制 ， 可 以 考虑 使 用 集群 并 行 执行 程序 。 既 然 单机 的 
资源 有 限制 ， 那 么 就 让 程序 在 多 机 上 运行 。 比 如 使 用 ODPS、Hadoop 或 
者 自己 搭建 服务 器 集群 ， 不 同 的 机 器 处 理 不 同 的 数据 。 可 以 通过 “数据 
ID% 机 器 数 "， 计 算得 到 一 个 机 器 编号 ， 然 后 由 对 应 编号 的 机 器 处 理 这 
笔 数 据 。 





对 于 软件 资源 限制 ， 可 以 考虑 使 用 资源 池 将 资源 复 用 。 比 如 使 用 连 
接 池 将 数据 库 和 Socket 连 接 复 用 ， 或 者 在 调用 对 方 webservice 接 口 获 取 
数据 时 ， 只 建立 一 个 连接 。 


(4) 在 资源 限制 情况 下 进行 并 友 编 程 





如 何在 资源 限制 的 情况 下 ， 让 程序 执行 得 更 快 呢 ? 方法 就 是 ， 根 气 
不 同 的 资源 限制 调整 程序 的 并 发 度 ， 比 如 下 载 文件 程序 依赖 于 两 个 资源 
帝 宽 和 硬盘 读 写 速度 。 有 数据 库 操 作 时 ， 涉 及 数据 库 连 接 数 ， 如 果 
SQL 语句 执行 非常 快 ， 而 线程 的 数量 比 数据 库 连 接 数 大 很 多 ， 则 茶 些 线 
程 会 被 阻 竖 ， 等 竺 数据库 连接 。 





1.4 本章 小 结 





本 章 介 绍 了 在 进行 并 发 编程 时 ， 大 家 可 能 会 遇 到 的 几 个 挑战 ， 并 给 
出 了 一 些 解决 建议 。 有 的 并 发 程序 写 得 不 严 说， 在 并 发 下 如 打出 现 问 
题 ， 定 位 起 来 会 比较 耗 时 和 环 手 。 所 以 ， 对 于 Java 开 发 工程 师 而 言 ， 笔 
者 强烈 建议 多 使 用 JDK 并 发 包 提 供 的 并 发 容器 和 工具 类 来 解决 并 发 问 
题 ， 因 为 这 些 类 都 已 经 通过 了 充分 的 测试 和 优化 ， 均 可 解决 了 本 章 提 到 
的 儿 个 挑战 。 


第 2 草 ”Java 并 友 机 制 的 奔 层 实现 原理 


Java 代 码 在 编译 后 会 变 成 Java 字 节 人 码 ， 字 节 码 被 类 加 载 器 加 载 到 
JVM 里 ，JVM 执 行 字 节 码 ， 最 终 需 要 转化 为 汇编 指令 在 CPU 上 执行 ， 
Java 中 所 使 用 的 并 发 机 制 依赖 于 JVM 的 实现 和 CPU 的 指令 。 本 章 我 们 将 
深入 底层 一 起 探索 下 Java 并 发 机 制 的 底层 实现 原理 。 





2.1 volatile 的 应 用 


在 多 线程 并 发 编程 中 Synchronized 和 volatile 都 扮演 着 重要 的 角色 ， 
volatile 是 轻 量 级 的 synchronized， 它 在 多 处 理 絮 开发 中 保证 了 共享 变量 
的 “可 见 性 *"。 可 见 性 的 意思 是 当 一 个 线程 修改 一 个 共 至 变量 时 ， 胃 外 一 
个 线程 能 读 到 这 个 修改 的 值 。 如 果 volatile 变 量 修饰 符 使 用 恰当 的 话 ， 它 
比 synchronized 的 使 用 和 执行 成 本 更 低 ， 因 为 它 不 会 引起 线程 上 下 文 的 
切换 和 调度 。 本 文 将 深入 分 析 在 硬件 层面 上 Intel 处 理 器 是 如 何 实现 
volatile 的 ， 通 过 深入 分 析 帮 助 我 们 正确 地 使 用 volatile 变 量 。 








我 们 先 从 了 解 volatile 的 定义 开始 。 





1.volatile 的 定义 与 实现 原理 


Java 语 言 规范 第 3 版 中 对 volatile 的 定义 如 下 : Java 编 程 语言 允许 线程 
访问 共 孚 变量 ， 为 了 确保 共享 变量 能 被 准确 和 一 致 地 更 新 ， 线 程 应 该 确 
保 通 过 排他 锁 单 独 获得 这 个 变量 。Java 语 言 提 供 了 volatile， 在 某 些 情况 
下 比 锁 要 更 加 方便 。 如 果 一 个 字段 被 声明 成 volatile，Java 线 程 内 存 模型 
确保 所 有 线程 看 到 这 个 变量 的 值 是 一 致 的 。 








在 了 解 volatile 实 现 原理 之 前 ， 我 们 先 来 看 下 与 其 实现 原理 相关 的 
CPU 术 语 与 说 明 。 表 2-1 是 CPU 术 语 的 定义 。 


表 2 


内 存 屏障 是 一 组 处 理 器 指令 ， 用 于 实现 对 内 存 操作 的 顺序 限制 
项 


缓冲 行 cache line 绥 存 中 可 以 分 配 的 最 小 存储 单位 。 处 理 器 填写 缓存 线 时 会 加 载 整个 
- 友 ! < jk ps s, HF fF A Ys | 
缓存 线 ， 需 要 使 用 多 个 主 内 存 读 周期 


原子 操作 atomic operations 不 可 中 断 的 一 个 或 一 系列 操作 
缓存 行 填充 he line fill 当 处 理 器 识别 到 从 内 存 中 读 取 操作 数 是 可 缓存 的 ， 处 理 器 读 取 整个 
缓存 行 填充 cache line fi a a Re re 
人 缓存 行 到 适当 的 缓存 (L1，L2，L3 的 或 所 有 ) 
om 如 果 进 行 高 速 缓存 行 填充 操作 的 内 存 位 置 仍然 是 下 次 处 理 需 访 问 的 
绥 存 命中 cache hit 人 RE en 

地 址 时 ， 处 理 右 从 缓存 中 读 取 操作 数 ， 而 不 是 从 内 存 读 取 


当 处 理 器 将 操作 数 写 回 到 一 个 内 存 缓存 的 区 域 时 ， 它 首先 会 检查 这 
个 缓存 的 内 存 地 址 是 否 在 缓存 行 中 ， 如 果 存 在 一 个 有 效 的 缓存 行 ， 则 


1 CPU 的 术语 定义 


写 命 中 write hit re ee et 

Sn 处 理 器 将 这 个 操作 数 写 回 到 缓存 ， 而 不 是 写 回 到 内 存 ， 这 个 操作 被 称 
为 写 命 中 

写 缺 失 write misses the cache 一 个 有 效 的 缓存 行 被 写 人 到 不 存在 的 内 存 区 域 





volatile 是 如 何 来 保证 可 见 性 的 呢 ? 让 我 们 在 X86 处 理 器 下 通过 工具 
获取 JIT 编 译 器 生成 的 汇编 指令 来 查看 对 volatile 进 行 写 操作 时 ，CPU 会 
做 什么 事情 。 


Java 代 码 如 下 。 





三 


instance = new Singleton(); // instance 是 volatile 变 量 











转变 成 汇编 代码 ， 如 下 。 





09x01a3de1d: movb $0x0, 0x1104800(%esi);0x91a3de24: lock addl $0x0, (%esp); 








有 volatile 变 量 修饰 的 共享 变量 进行 写 操作 的 时 候 会 多 出 第 二 行 汇编 
代码 ， 通 过 奋 IA-32 架 构 软 件 开 发 者 手册 可 知 ，Lock 前 绥 的 指令 在 多 核 





处 理 器 下 会 引发 了 两 件 事情 中。 


1) 将 当前 处 理 需 缓存 行 的 数据 写 回 到 系统 内 存 。 


2) 这 个 写 回 内存 的 操作 会 使 在 其 他 CPU 里 缓存 了 该 内 存 地 址 的 数 
据 无 效 。 





为 了 提高 处 理 速度 ， 处 理 器 不 直接 和 内 存 进行 通信 ， 而 是 先 将 系统 
内 存 的 数据 读 到 内 部 缓存 (L1，L2 或 其 他 ) 后 再 进行 操作 ， 但 操作 完 
不 知道 何 时 会 写 到 内 存 。 如 果 对 声明 了 volatile 的 变量 进行 写 操作 ，JVM 
就 会 向 处 理 器 发 送 一 条 Lock 前 缀 的 指令 ， 将 这 个 变量 所 在 缓存 行 的 数据 
写 回 到 系统 内 存 。 但 是 ， 就 算 写 回 到 内 存 ， 如 果 其 他 处 理 器 缓存 的 值 还 
是 旧 的 ， 再 执行 计算 操作 就 会 有 问题 。 所 以 ， 在 多 处 理 器 下 ， 为 了 保证 
各 个 处 理 器 的 缓存 是 一 致 的 ， 就 会 实现 缓存 一 致 性 协议 ， 每 个 处 理 器 通 
过 嗅 探 在 总 线 上 传播 的 数据 来 检查 自己 缓存 的 值 是 不 是 过 期 了 ， 当 处 理 
器 发 现 自己 缓存 行 对 应 的 内 存 地 址 被 修改 ， 就 会 将 当前 处 理 器 的 缓存 行 
设置 成 无 效 状 态 ， 当 处 理 器 对 这 个 数据 进行 修改 操作 的 时 候 ， 会 重新 从 
系统 内 存 中 把 数据 读 到 处 理 器 缓存 里 。 




















下 面 来 具体 讲解 volatile 的 两 条 实现 原则 。 


1) Lock 前 级 指令 会 引起 处 理 器 绥 存 回 写 到 内 存 。Lock 前 级 指令 导 
致 在 执行 指令 期 间 ， 声 言 处 理 器 的 LOCK# 信 号 。 在 多 处 理 器 环境 中 ， 
LOCK# 信 号 确保 在 声言 该 信号 期 间 ， 处 理 器 可 以 独占 任何 共享 内 存 吕 | 


。 但 是 ， 在 最 近 的 处 理 器 里 ，LOCK# 信 号 一 般 不 锁 总 线 ， 而 是 锁 绥 

存 ， 毕 况 锁 总 线 开销 的 比较 大 。 在 8.1.4 节 有 详细 说 明 锁 定 操作 对 处 理 器 
缓存 的 影响 ， 对 于 Intel486 和 Pentium 人 处 理 器 ， 在 锁 操 作 时 ， 总 是 在 总 线 
上 声言 LOCK# 信 号 。 但 在 P6 和 目前 的 处 理 器 中 ， 如 果 访 问 的 内 存 区 域 
已 经 缓存 在 处 理 器 内 部 ， 则 不 会 声言 LOCK# 信 和 号。 相反 ， 它 会 锁定 这 
块 内 存 区 域 的 缓存 并 回 写 到 内 存 ， 并 使 用 绥 存 一 致 性 机 制 来 确保 修改 的 
原子 性 ， 此 操作 被 称 为 “缓存 锁定 ”>， 缓 存 一 致 性 机 制 会 阻止 同时 修改 由 
两 个 以 上 处 理 需 缓存 的 内 存 区 域 数 据 。 








2) 一 个 处 理 器 的 缓存 回 写 到 内 存 会 导致 其 他 处 理 器 的 缓存 无 效 。 
IA-32 处 理 器 和 Intel 64 处 理 器 使 用 MESI 修改、 独占 、 共 享 、 无 效 ) 控 
制 协议 去 维护 内 部 缓存 和 其 他 处 理 器 缓存 的 一 致 性 。 在 多 核 处 理 器 系统 
中 进行 操作 的 时 候 ，IA-32 和 Intel 64 处 理 器 能 嗅 探 其 他 处 理 器 访问 系统 
内 存 和 它们 的 内 部 缓存 。 处 理 器 使 用 嗅 探 技术 保 证 它 的 内 部 缓存 、 系 统 
内 存 和 其 他 处 理 器 的 缓存 的 数据 在 总 线 上 保持 一 致 。 例 如 ， 在 Pentium 
和 P6 family 处 理 嚣 中， 如 果 通 过 咒 探 一 个 处 理 器 来 检测 其 他 处 理 器 打算 
写 内 存 地 址 ， 而 这 个 地 址 当前 处 于 共享 状态 ， 那 么 正在 嗅 探 的 处 理 器 将 
使 它 的 缓存 行 无 效 ， 在 下 次 访问 相同 内 存 地址 时 ， 强 制 执 行 缓存 行 填 
pi 








2.volatile 的 使 用 优化 


著名 的 Java 并 发 编程 大 师 Doug lea 在 JDK 7 的 并 发 包 里 新 增 一 个 队列 
集合 类 Linked-TransferQueue， 它 在 使 用 volatile 变 量 时 ， 用 一 种 追加 字 节 
的 方式 来 优化 队列 出 队 和 入 队 的 性 能 。LinkedTransferQueue 的 代码 如 
加 





A/** 队列 中 的 头 部 节点 */ 

private transient f?inal PaddedAtomicReference<QNode> head; 

A/** 队列 中 的 尾部 节点 */ 

private transient f?inal PaddedAtomicReference<QNode> tail; 

static f?inal class PaddedAtomicReference <T> extends AtomicReference T> { 
// 使 用 很 多 4 个 字 节 的 引用 追加 到 64 个 字 节 
Object pO, pi, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pe, pd, pe; 
PaddedAtomicReference(T r) { 

super(r); 

















public class AtomicReference <V> implements java.io.Serializable 区 
private volatile V value; 


// 省 略 其 他 代码 














} 





妃 加 字 市 能 优化 性 能 ? 这 种 方式 看 起 来 很 神奇 ， 但 如 果 深 入 理解 
处 理 器 架构 就 能 理解 其 中 的 奥秘 。 让 我 们 先 来 看 看 LinkedTransferQueue 
这 个 类 ， 它 使 用 一 个 内 部 类 类 型 来 定义 队列 的 头 节 点 (head) 和 尾 节 点 
Ctail) ， 而 这 个 内 部 类 PaddedAtomicReference 相 对 于 父 类 
AtomicReference 只 做 了 一 件 事 情 ， 束 是 将 共 孚 变量 退 加 到 64 字 节 。 我 们 
可 以 来 计算 下 ， 一 个 对 象 的 引用 占 4 个 字 节 ， 它 追加 了 15 个 变量 〈 共 占 


60 个 字 节 ) ， 再 加 上 父 类 的 value 变 量 ， 一 共 64 个 字 节 。 


为 什么 人 奶 加 64 字 节能 够 提高 并 发 编程 的 效率 呢 ? 因为 对 于 英特尔 
酷 害 17、 酷 害 、Atom 和 NetBurst， 以 及 Core Solo 和 Pentium M 处 理 器 的 


L1、L2 或 L3 缓 存 的 高 速 缓存 行 是 64 个 字 节 宽 ， 不 文 持 部 分 填充 缓存 

















行 ， 这 意味 着 ， 如 果 队 列 的 关节 点 和 尾 节 点 都 不 足 64 字 贡 的 话 ， 处 理 需 
会 将 它们 都 读 到 同一 个 高 速 缓存 行 中 ， 在 多 处 理 需 下 每 个 处 理 器 都 会 组 
存 同样 的 头 、 尾 节点 ， 当 一 个 处 理 器 试图 修改 头 节 点 时 ， 会 将 整个 缓存 
行 锁定 ， 那 么 在 缓存 一 致 性 机 制 的 作用 下 ， 会 导致 其 他 处 理 需 不 能 访问 
目 己 高 速 缓存 中 的 尾 节 点 ， 而 队列 的 入 队 和 出 队 操作 则 需要 不 停 修改 头 
闻 点 和 尾市 把， 所 以 在 多 处 理 占 的 情况 下 将 会 严重 影响 到 队列 的 入 队 和 
出 队 效 率 。Doug lea 使 用 追加 到 64 字 节 的 方式 来 填 满 高 速 缓冲 区 的 缓存 
行 ， 避 免 头 节点 和 尾市 氮 加 载 到 同一 个 缓存 行 ， 使 头 、 尾 节点 在 修改 时 
不 会 互相 锁定 。 

















那么 是 不 是 在 使 用 volatile 变 量 时 都 应 该 退 加 到 64 字 节 了 呢 ? 不 是 
的 。 在 两 种 场景 下 不 应 该 使 用 这 种 方式 。 





. 缓存 行 非 64 字 节 宽 的 处 理 器 。 如 P6 系 列 和 奔腾 处 理 器 ， 它 们 的 


L1 和 L2 高 速 缓存 行 是 32 个 字 节 宽 。 


享 变量 不 会 被 频 繁 地 写 。 因 为 使 用 追加 字 节 的 方式 需要 处 理 
器 读 取 更 多 的 字 节 到 高 速 缓冲 区 ， 这 本 身 就 会 带 来 一 定 的 性 能 消耗 ， 如 
果 共 享 变 量 不 被 频繁 写 的 话 ， 锁 的 几率 也 非常 小 ， 就 没 必 要 通过 追加 字 
节 的 方式 来 避免 相互 锁定 。 


不 过 这 种 追加 字 节 的 方式 在 Java 7 下 可 能 不 生效 ， 因 为 Java 7 变 得 更 
加 智 芒 ， 它 会 淘汰 或 重新 排列 无 用 字段 ， 需 要 使 用 其 他 退 加 字 市 的 方 











式 。 除 了 volatile，Java 并 发 编程 中 应 用 较 多 的 是 synchronized， 下 面 一 起 
有 灯 看 一 下 。 


[1] 这 两 件 事情 在 IA-32 软 件 开发 者 架构 手册 的 第 三 册 的 多 处 理 器 管理 章 
节 (第 8 章 ) 中 有 详细 阅 述 。 
[2] 因为 它 会 锁 住 总 线 ， 导 致 其 他 CPU 不 能 访问 总 线 ， 不 能 访问 总 线 就 意 


味 着 不 能 访问 系统 内 存 。 


2.2 synchronized 的 实现 原理 与 应 用 


在 多 线程 并 发 编程 中 synchronized 一 直 是 元 老 级 角色 ， 很 多 人 都 会 
称呼 它 为 重量 级 锁 。 但 是 ， 随 着 Java SE 1.6 对 Synchronized 进 行 了 各 种 优 
化 之 后 ， 有 些 情况 下 它 束 并 不 那么 重 了 。 本 文 详细 介绍 Java SE 1.6 中 为 
了 减少 获得 锁 和 释放 锁 市 来 的 性 能 消耗 而 引入 的 偏 问 锁 和 轻 量 级 锁 ， 以 
及 锁 的 存储 结构 和 升级 过 程 。 

先 来 看 下 利用 synchronized 实 现 同步 的 基础 : Java 中 的 每 一 个 对 象 都 
可 以 作为 锁 。 有 共 体 表现 为 以 下 3 种 形式 。 


. 对 于 普通 同步 方法 ， 锁 是 当前 实例 对 象 。 
. 对 于 静态 同步 方法 ， 锁 是 当前 类 的 Class 对 象 。 


. 对 于 同步 方法 块 ， 锁 是 Synchonized 括 号 里 配置 的 对 象 。 





当 一 个 线程 试图 访问 同步 代码 块 时 ， 它 首先 必须 得 到 锁 ， 退 出 或 抛 
出 异 第 时 必须 释放 锁 。 那 么 锁 到 拘 存 在 哪里 呢 ? 锁 里 面 会 存储 什么 信息 
呢 ? 


从 JVM 规 范 中 可 以 看 到 Synchonized 在 JVM 里 的 实现 原理 ，JVM 基 于 
进入 和 退出 Monitor 对 象 来 实现 方法 同步 和 代码 块 同步 ， 但 两 者 的 实现 
细节 不 一 样 。 代 码 块 同步 是 使 用 monitorenter 和 monitorexit 指 令 实 现 的 ， 





而 方法 同步 是 使 用 另外 一 种 方式 实现 的 ， 细 节 在 JVM 规 范 里 并 没有 详细 
说 明 。 但 是 ， 方 法 的 同步 同样 可 以 使 用 这 两 个 指令 来 实现 。 


monitorenter 指 令 是 在 编译 后 插入 到 同步 代码 块 的 开始 位 置 ， 而 
monitorexit 是 插入 到 方法 结束 处 和 异常 处 ，JVM 要 保证 每 个 monitorenter 
必须 有 对 应 的 monitorexit 与 之 配对 。 任 何 对 象 都 有 一 个 monitor 与 之 关 
联 ， 当 且 一 个 monitor 被 持 有 后 ， 它 将 处 于 锁定 状态 。 线 程 执行 到 
monitorenter 指 令 时 ， 将 会 尝试 获取 对 象 所 对 应 的 monitor 的 所 有 权 ， 即 
尝试 获得 对 象 的 锁 。 


2.2.1 Java 对 象 头 





synchronized 用 的 锁 是 存在 Java 对 象 头 里 的 。 如 果 对 象 是 数组 类 型 ， 
则 虚拟 机 用 3 个 字 宽 (Word) 存储 对 象 头 ， 如 果 对 象 是 非 数组 类 型 ， 则 
用 2 字 宽 存储 对 象 头 。 在 32 位 虚拟 机 中 ，1 字 宽 等 于 4 字 节 ， 即 32bit， 如 
表 2-2 所 示 。 





表 2-2 Java 对象 头 的 长 度 






















32/64bit 
32/64bit 


32/32bit 


Mark Word 
Class Metadata Address 


存储 对 象 的 hashCode 或 锁 信 息 等 
存储 到 对 象 类 型 数据 的 指针 
数组 的 长 度 (如 果 当 前 对 象 是 数组 ) 





Java 对 象 头 里 的 Mark Word 里 默认 存储 对 象 的 HashCode、 分 代 年 龄 
和 锁 标 记 位 。32 位 JVM 的 Mark Word 的 默认 存储 结构 如 表 2-3 所 示 。 


表 2-3 Java 对 象 头 的 存储 结构 


锁 状 态 25bit 1bit 是 否 是 偏向 锁 2bit 锁 标志 位 
无 锁 状态 对 象 的 hashCode 对 象 分 代 年 龄 | 0 | 01 





在 运行 期 间 ，Mark Word 里 存储 的 数据 会 随 着 锁 标 志 位 的 变化 而 变 
化 。Mark Word 可 能 变化 为 存储 以 下 4 种 数据 ， 如 表 2-4 所 示 。 


表 2-4 Matk Word 的 状态 变化 


是 否 是 偏向 锁 锁 标 志 位 


指向 栈 中 锁 记 录 
指 疝 互 斥 量 


线程 D 





表 2-5 Matk Word 的 存储 结构 


a 到 
| | res | | 仙山 | 名 标志 
| ua | ia | | |。 | nm 
Rn | po | | | | 





2.2.2” 锁 的 升级 与 对 比 


Java SE 1.6 为 了 减少 获得 锁 和 释放 锁 融 来 的 性 能 消耗 ， 引 入 了 "偏向 
锁 ” 和 * 轻 量 级 锁 ?， 在 Java SE 1.6 中 ， 锁 一 共有 4 种 状态 ， 级 别 从 低 到 高 
依次 是 : 无 锁 状 态 、 偏 向 锁 状 态 、 轻 量 级 锁 状 态 和 重量 级 锁 状 态 ， 这 几 
个 状态 会 随 着 竞争 情况 逐渐 升级 。 锁 可 以 升级 但 不 能 降级 ， 意 味 着 偏 癌 
锁 升 级 成 轻 量 级 锁 后 不 能 降级 成 偏 癌 锁 。 这 种 锁 升 级 却 不 能 降级 的 策 
略 ， 目 的 是 为 了 提高 获得 锁 和 释放 锁 的 效率 ， 下 文 会 详细 分 析 。 








1. 仿 问 锁 








HotSpot 01 的 作者 经 过 研究 发 现 ， 大 多 数 情况 下 ， 锁 不 仅 不 存在 多 
线程 竞争 ， 而 且 总 是 由 同一 线程 多 次 获得 ， 为 了 让 线程 获得 锁 的 代价 更 
低 而 引入 了 偏向 锁 。 当 一 个 线程 访问 同步 块 并 获取 锁 时 ， 会 在 对 象 尖 和 
栈 帧 中 的 锁 记 录 里 存储 锁 偏向 的 线程 ID， 以 后 该 线程 在 进入 和 退出 同步 
块 时 不 需要 进行 CAS 操 作 来 加 锁 和 人 解锁， 只 震 简 单 地 测试 一 下 对 象 尖 的 
Mark Word 里 是 否 存储 着 指 向 当前 线程 的 偏向 锁 。 如 果 测 试 成 功 ， 表 示 
线程 已 经 获得 了 锁 。 如 果 测 试 失败 ， 则 需要 再 测试 一 下 Mark Word 中 依 
回 锁 的 标识 是 否 设 置 成 1 (表示 当前 是 仿 癌 锁 ): 如 果 没 有 设置 ， 则 使 
用 CAS 苋 争 锁 ;， 如 果 设 置 了 ， 则 尝试 使 用 CAS 将 对 象 头 的 偏 问 锁 指 癌 当 


前 线程 。 

















(1) 偏向 锁 的 撤销 


偏 回 锁 使 用 了 一 种 等 到 苋 争 出 现 才 释放 锁 的 机 制 ， 所 以 当 其 他 线程 
尝试 范 争 偏 同 锁 时 ， 持 有 仿 向 锁 的 线程 才 会 释放 锁 。 偏 向 锁 的 撤销 ， 般 
要 等 待 全 局 安全 点 《在 这 个 时 间 点 上 没有 正在 执行 的 字 节 码 ) 。 它 会 首 
先 暂停 拥有 偶 癌 锁 的 线程 ， 然 后 检查 持 有 偶 问 锁 的 线程 是 人 否 活 者 ， 如 果 
线程 不 处 于 活动 状态 ， 则 将 对 象 尖 设置 成 无 锁 状 态 ， 如 果 线 程 仍然 活 
者 ， 拥 有 仿 癌 锁 的 栈 会 被 执行 ， 过 历 侦 癌 对 象 的 锁 记 录 ， 栈 中 的 锁 记 录 
和 对 象 头 的 Mark Word 要 么 重新 偶 癌 于 其 他 线程 ， 要 么 恢复 到 无 锁 或 者 
标记 对 象 不 适合 作为 偏 回 锁 ， 最 后 唤醒 暂停 的 线程 。 图 2-1 中 的 线程 1 演 
示 了 偏向 锁 初 始 化 的 流程 ， 线 程 2 演 示 了 仿 占 锁 撤销 的 流程 。 

















偏向 锁 的 获得 和 撤销 流程 
线程 1 对 和 象 头 中 的 Mark Word 


访问 同步 块 


检查 对 象 头 中 
是 否 存储 了 线程 1 


访问 同步 块 


将 对 象 头 Mark 
Word 中 的 线程 
ID 指向 自己 


撤销 偏向 锁 


解锁 ， 将 线程 
1D 设 为 空 


恢复 线程 











图 2-1 偏向 锁 初始 化 的 流程 


(2) 关闭 偏 问 锁 


偏向 锁 在 Java 6 和 Java 7 里 是 默认 启用 的 ， 但 是 它 在 应 用 程序 启动 几 
秒 钟 之 后 才 激 活 ， 如 有 必要 可 以 使 用 JVM 参 数 来 关闭 延迟 : - 
XX:BiasedLockingStartupDelay=0。 如 果 你 确定 应 用 程序 里 所 有 的 锁 通 常 
情况 下 处 于 竞争 状态 ， 可 以 通过 JVM 人 参数 关闭 偏向 锁 : -XX:- 
UseBiasedLocking=false， 那 么 程序 默认 会 进入 轻 量 级 锁 状 态 。 


2. 轻 量 级 锁 


(1) 轻 量 级 锁 加 锁 


线程 在 执行 同步 块 之 前 ，JVM 会 先 在 当前 线程 的 栈 桢 中 创建 用 于 存 
储 锁 记 录 的 空间 ， 并 将 对 象 头 中 的 Mark Word 复 制 到 锁 记录 中 ， 官 方 称 
为 Displaced Mark Word。 然 后 线程 尝试 使 用 CAS 将 对 象 头 中 的 Mark 
Word 替 换 为 指向 锁 记 录 的 指针 。 如 果 成 功 ， 当 前 线程 获得 锁 ， 如 果 失 
败 ， 表 示 其 他 线程 竞争 锁 ， 当 前 线程 便 尝 试 使 用 自 旋 来 获取 锁 。 


(2) 轻 量 级 锁 解 锁 


轻 量 级 解锁 时 ， 会 使 用 原子 的 CAS 操 作 将 Displaced Mark Word 蔡 换 
回 到 对 象 头 ， 如 果 成 功 ， 则 表示 没有 竞争 发 生 。 如 果 失 败 ， 表 示 当 前 锁 
存在 竞争 ， 锁 就 会 膨胀 成 重量 级 锁 。 图 2-2 是 两 个 线程 同时 争夺 锁 ， 导 
致 锁 膨 胀 的 流程 图 。 


轻 量 级 锁 及 膨胀 流程 图 
































线程 1 Mark Word 的 变化 
访问 同步 块 访问 同步 块 
P 分 配 空间 并 复制 | HashCodelagel | 分 配 空间 并 复制 

起 Mark Word 到 栈 0I01 Mark Word 到 栈 

党 

上 

CAS 修 改 
Mark Word 
将 Mark Word 
替换 为 轻 量 级 锁 
吓 
绰 
CAS 替 换 Me Es BIE 

六 失败 ， 因 线程 2 在 争夺 锁 

I 

es 释放 锁 

司 等 待 的 线程 

AN 

7 | 
线程 被 唤醒 ， 重 新 
争夺 锁 访 问 同 步 块 

















图 2-2 ”争夺 锁 导 致 的 锁 膨 胀 流程 图 


因为 目 旋 会 消耗 CPU， 为 了 避免 无 用 的 目 旋 《〈“ 比 如 获得 锁 的 线程 被 
阻塞 住 了 ) ， 一 旦 锁 升 级 成 重量 级 锁 ， 就 不 会 再 恢复 到 轻 量 级 锁 状 态 。 
当 锁 处 于 这 个 状态 下 ， 其 他 线程 试图 获取 锁 时 ， 都 会 被 阻 竖 住 ， 当 持 有 
锁 的 线程 释放 锁 之 后 会 唤醒 这 些 线程 ， 被 唤醒 的 线程 就 会 进行 新 一 轮 的 


夺 锁 之 争 。 


3. 锁 的 优 缺 点 对 比 


表 2-6 是 锁 的 优 缺 点 的 对 比 。 


表 2-6 ” 锁 的 优 缺 点 的 对 比 


锁 适用 场景 
偏向 蚀 加 钙 和 解锁 不 需要 额外 的 消 桥 ， 和 执 如 果 线 程 间 存 在 锁 竞 争 , | 适用 于 只 有 一 个 线程 访 
行 非 同步 方法 相 比 仅 存在 纳 秒 级 的 差距 | 会 带 来 额外 的 锁 撤 销 的 消耗 | 问 同步 块 场景 
轻 量 级 锁 竞争 的 线程 不 会 阻塞 ， 提 高 了 程序 的 | 如 果 始 终 得 不 到 锁 竞 争 的 | 追求 响应 时 间 
”响应 速度 线程 ， 使 用 自 旋 会 消耗 CPU a 非常 快 
自 求 吞吐 量 


i 量 级 锁 时 D ` 会 线 但 民 塞 ， 啊 应 下 上 缓慢 
重量 级 锁 划 程 竞争 不 使 用 自 旋 ， 不 会 消耗 CPU | ”线程 阻塞 ， 响 应 时 间 缓 es 





[1 本 节 一 些 内 容 参 考 了 HotSpot 源 码 、 对 象 头 源码 markOop.hpp、 偏 向 锁 
源码 biasedLocking.cpp， 以 及 其 他 源码 ObjectMonitor.cpp 和 


BasicLock.cpp。 


2.3 ”原子 操作 的 实现 原理 





原子 (atomic) 本 意 是 “不 能 被 进一步 分 割 的 最 小 粒子 ”， 而 原子 操 
作 (atomic operation) 意 为 “不 可 被 中 断 的 一 个 或 一 系列 操作 ”"。 在 多 处 
理 右 上 实现 原子 操作 就 变 得 有 点 复杂 。 让 我 们 一 起 来 聊 一 聊 在 Intel 处 理 
项 和 Java 里 是 如 何 实现 原子 操作 的 。 








1. 术 语 定 义 


在 了 解 原 子 操作 的 实现 原理 前 ， 先 要 了 解 一 下 相关 的 术语 ， 如 表 2- 


7 所 示 。 


表 2-7 CPU 术 语 定义 


术语 名 称 英 文 解释 
缓存 行 Cache line 缓存 的 最 小 操作 单位 
CAS 操作 需要 输入 两 个 数值 ， 一 个 旧 值 (期望 操作 前 的 值 ) 和 
比较 并 交换 Compare and Swap 一 个 新 值 ， 在 操作 期 间 先 比较 旧 值 有 没有 发 生变 化 ， 如 果 没 有 发 
生变 化 ， 才 交换 成 新 值 ， 发 生 了 变化 则 不 交换 


| Cacheline 
CPU 流水 线 的 工作 方式 就 像 工业 生产 上 的 装配 流水 线 ， 在 CPU 
中 由 5 ~ 6 个 不 同 功能 的 电路 单元 组 成 一 条 指令 处 理 流水 线 ， 然 
CPU 流水 线 CPU pipeline 后 将 一 条 X86 指令 分 成 5 ~ 6 步 后 再 由 这 些 电路 单元 分 别 执行 ， 
这 样 就 能 实现 在 一 个 CPU 时 钟 周期 完成 一 条 指令 ， 因 此 提高 CPU 
的 运算 速度 


内 存 顺 序 冲 突 一 般 是 由 假 共 享 引 起 的 ， 假 共享 是 指 多 个 CPU 同 
内 存 顺 序 冲突 Memory order violation | 时 修改 同一 个 缓存 行 的 不 同 部 分 而 引起 其 中 一 个 CPU 的 操作 无 
效 ， 当 出 现 这 个 内 存 顺序 冲突 时 ，CPU 必须 清空 流水 线 





2. 处 理 絮 如何 实 现 原子 操作 








32 位 IA-32 处 理 堪 使 用 基于 对 缓存 加 锁 或 总 线 加 锁 的 方式 来 实现 多 
处 理 器 之 间 的 原子 操作 。 首 先 处 理 器 会 自动 保证 基本 的 内 存 操作 的 原子 
性 。 处 理 器 保证 从 系统 内 存 中 读 取 或 者 写 入 一 个 字 节 是 原子 的 ， 意 思 是 
当 一 个 处 理 器 读 取 一 个 字 节 时 ， 其 他 处 理 器 不 能 访问 这 个 字 节 的 内 存 地 
址 。Pentium 6 和 最 新 的 处 理 器 能 自动 保证 单 处 理 器 对 同一 个 缓存 行 里 进 
行 16/32/64 位 的 操作 是 原子 的 ， 但 是 复杂 的 内 存 操作 处 理 器 是 不 能 自动 
保证 其 原子 性 的 ， 比 如 跨 总 线 宽度 、 跨 多 个 缓存 行 和 跨 页 表 的 访问 。 但 
是 ， 处 理 器 提供 总 线 锁定 和 缓存 锁定 两 个 机 制 来 保证 复杂 内 存 操作 的 原 
1 


(1) 使 用 总 线 锁 保 证 原子 性 


第 一 个 机 制 是 通过 总 线 锁 保 证 原子 性 。 如 果 多 个 处 理 器 同时 对 共 
享 变量 进行 读 改 写 操作 〈i++ 就 是 经 典 的 读 改 写 操作 ) ， 那 么 共享 变量 
就 会 被 多 个 处 理 器 同时 进行 操作 ， 这 样 读 改 写 操作 就 不 是 原子 的 ， 操 作 
完 之 后 共享 变量 的 值 会 和 期 望 的 不 一 致 。 举 个 例子 ， 如 果 i=1， 我 们 进 
行 两 次 it+ 操 作 ， 我 们 期 望 的 结果 是 3， 但 是 有 可 能 结果 是 2， 如 图 2-3 所 


作 \。 






































| 
! 半 = 骂 1 
图 2-3 ”结果 对 比 


原因 可 能 是 多 个 处 理 器 同时 从 各 自 的 缓存 中 读 取 变量 1， 分 别 进行 
加 1 操作 ， 然 后 分 别 写 入 系统 内 存 中 。 那 么 ， 想 要 保证 读 改 写 共 享 变 量 
的 操作 是 原子 的 ， 就 必须 保证 CPU1 读 改写 共享 变量 的 时 候 ，CPU2 不 能 





操作 缓存 了 该 共享 变量 内 存 地 址 的 缓存 。 


处 理 器 使 用 总 线 锁 就 是 来 解决 这 个 问题 的 。 所 谓 总 线 锁 就 是 使 用 处 
理 器 提供 的 一 个 LOCK## 信 号 ， 当 一 个 处 理 器 在 总 线 上 输出 此 信号 时 ， 


其 他 处 理 器 的 请 求 将 被 阻塞 住 ， 那 么 该 处 理 器 可 以 独占 共 胖 内 存 。 


(2) 使 用 缓存 锁 保 证 原子 性 


第 二 个 机 制 是 通过 缓存 锁定 来 保证 原子 性 。 在 同一 时 刻 ， 我 们 只 
天 保证 对 茶 个 内 存 地 址 的 操作 是 原子 性 即 可 ， 但 总 线 锁定 把 CPU 和 内 存 


之 间 的 通信 锁 住 了 ， 这 使 得 锁定 期 间 ， 其 他 处 理 需 不 能 操作 其 他 内 存 地 
址 的 数据 ， 所 以 总 线 锁定 的 开销 比较 大 ， 目 前 处 理 需 在 东 些 场合 下 使 用 
绥 存 锁定 代 蔡 总 线 锁定 来 进行 优化 。 


频繁 使 用 的 内 存 会 缓存 在 处 理 器 的 L1、L2 和 L3 高 速 缓 在 里， 那么 

原子 操作 就 可 以 直接 在 处 理 器 内 部 缓存 中 进行 ， 并 不 需要 声明 总 线 锁 ， 
在 Pentium 6 和 目前 的 处 理 器 中 可 以 使 用 “缓存 锁定 ”的 方式 来 实现 复杂 的 
原子 性 。 所 谓 “ 缓 存 锁定 ”是 指 内 存 区 域 如 果 被 缓存 在 处 理 器 的 缓存 行 

中 ， 并 且 在 Lock 操 作 期 间 被 锁定 ， 那 么 当 它 执行 锁 操 作 回 写 到 内 存 时 ， 
处 理 堪 不 在 总 线 上 声言 LOCK 并 信号 ， 而 是 修改 内 部 的 内 存 地 址 ， 并 多 
许 它 的 缓存 一 致 性 机 制 来 保证 操作 的 原子 性 ， 因 为 缓存 一 致 性 机 制 会 阻 
止 同 时 修改 由 两 个 以 上 处 理 器 缓存 的 内 存 区 域 数 据 ， 当 其 他 处 理 器 回 写 
已 被 锁定 的 缓存 行 的 数据 时 ， 会 使 缓存 行 无 效 ， 在 如 图 2-3 所 示 的 例子 
中 ， 当 CPU1 修 改 缓存 行 中 的 i 时 使 用 了 缓存 锁定 ， 那 么 CPU2 就 不 能 同时 
缓存 i 的 缓存 行 。 











但 是 有 两 种 情况 下 处 理 器 不 会 使 用 缓存 锁定 。 


第 一 种 情况 是 : 当 操 作 的 数据 不 能 被 缓存 在 处 理 器 内 部 ， 或 操作 的 
数据 路 多 个 缓存 行 (cache line) 时 ， 则 处 理 器 会 调用 总 线 锁定 。 


第 二 种 情况 是 : 有 些 处 理 圳 不 文 持 缓存 锁定 。 对 于 Intel 486 和 
Pentium 处 理 器 ， 就 算 锁 定 的 内 存 区 域 在 处 理 需 的 缓存 行 中 也 会 调用 总 


线 锁定 。 


针对 以 上 两 个 机 制 ， 我 们 通过 Intel 处 理 器 提供 了 很 多 Lock 前 级 的 指 
令 来 实现 。 例 如 ， 位 测试 和 修改 指令 : BTS、BTR、BTC; 交换 指令 
XADD、CMPXCHG， 以 及 其 他 一 些 操作 数 和 逻辑 指令 (如 ADD、 
OR) 等 ， 被 这 些 指令 操作 的 内 存 区 域 就 会 加 锁 ， 导 致 其 他 处 理 器 不 能 
同时 访问 它 。 


3.Java 如 何 实现 原子 操作 








在 Java 中 可 以 通过 锁 和 循环 CAS 的 方式 来 实现 原子 操作 。 


(1) 使 用 循环 CAS 实 现 原子 操作 


JVM 中 的 CAS 操 作 正 是 利用 了 处 理 器 提供 的 CMPXCHG 指 令 实现 
的 。 自 旋 CAS 实 现 的 基本 思路 就 是 循环 进行 CAS 操 作 直 到 成 功 为 止 ， 以 
下 代码 实现 了 一 个 基于 CAS 线 程 安全 的 计数 器 方法 safeCount 和 一 个 非 线 
程 安全 的 计数 器 count。 








private AtomicInteger atomicI = new AtomicIinteger(0); 
private int i = 0 
public static void main(String[] args) { 
final Counter cas = new Counter(); 
List<Thread> ts = new ArrayList<Thread>(600); 
long start = System.currentTimeMillis(); 
for (int j = 0; j < 100; j++) { 
Thread t = new Thread(new Runnable() { 
@Override 
public void run() { 
for (int i = 0; i < 10000; i++) { 
cas.count(); 
cas.safeCount(); 


} 


} 
}); 
ts.add(t); 


} 
for (Thread t : ts) { 
t.start(); 


} 
// 等 待 所 有 线程 执行 完成 
for (Thread t : ts) { 
try { 
t .join(); 
} catch (InterruptedException e) { 
e.printStackTrace(); 


System.out.println(cas.i); 
System.out.printin(cas.atomicI.get()); 
System.out.printlin(System.currentTimeMillis() - start); 

















} 
ee * 使 用 CAS 实 现 线程 安全 计数 器 */ 
private void safeCount() { 
for (;;) { 
int i = atomicI.get(); 
boolean Suc = atomicI.compareAndSet(i, ++i); 











if (suc) { 
break; 
} 
} 
* 非 线程 安 全 计数 器 
yA 


private void count() { 
+ 十 》 
} 





从 Java 1.5 开 始 ，JDK 的 并 发 包 里 提供 了 一 些 类 来 文 持原 子 操作 ， 如 


AtomicBoolean 〈 用 原子 方式 更 新 的 boolean 值 ) 、AtomicInteger〈 用 原 
子 方式 更 新 的 int 值 ) 和 AtomicLong 〈 用 原子 方式 更 新 的 long 值 ) 。 这 些 
原子 包装 类 还 提供 了 有 用 的 工具 方法 ， 比 如 以 原子 的 方式 将 当前 值 自 增 


1 和 目 减 1。 


(2) CAS 实 现 原子 操作 的 三 大 问题 











在 Java 并 发 包 中 有 一 些 并 发 框架 也 使 用 了 上 自 旋 CAS 的 方式 来 实现 原 


子 操 作 ， 比 如 LinkedTransferQueue 类 的 Xfer 方 法 。CAS 虽 然 很 高 效 地 解 
决 了 原子 操作 ， 但 是 CAS 仍 然 存 在 三 大 问题 。ABA 问 题 ， 循 环 时 间 长 开 
销 大 ， 以 及 只 能 保证 一 个 共享 变量 的 原子 操作 。 





1) ABA 问 题 。 因 为 CAS 需 要 在 操作 值 的 时 候 ， 检 查 值 有 没有 发 生 
变化 ， 如 果 没 有 发 生变 化 则 更 新 ， 但 是 如 果 一 个 值 原 来 是 A， 变 成 了 
B， 又 变 成 了 A， 那 么 使 用 CAS 进 行 检查 时 会 发 现 它 的 值 没 有 发 生变 
化 ， 但 是 实际 上 却 变 化 了 。ABA 问 题 的 解决 思路 就 是 使 用 版 本 号 。 在 变 
量 前 面 妃 加 上 版 本 号 ， 每 次 变量 更 新 的 时 候 把 版 本 号 加 1， 那 么 
A-B-A 就 会 变 成 1IA-2B-3A。 从 Java 1.5 开 始 ，JDK 的 Atomic 包 里 提 














供 了 一 个 类 AtomicStampedReference 来 解决 ABA 问 题 。 这 个 次 的 
compareAndSet 方 法 的 作用 是 首先 检查 当前 引用 是 否 等 于 预期 引用 ， 并 
且 检 和 碍 当前 标志 是 否 等 于 预期 标志 ， 如 果 全 部 相等 ， 则 以 原子 方式 将 访 
引用 和 该 标志 的 值 设 置 为 给 定 的 更 新 值 。 


























public boolean compareAndSet( 
V 





























expectedReference, // 预期 引用 
V newReference, // 更 新 后 的 引用 
int expectedstamp, // 预期 标志 
int newStamp // 更 新 后 的 标志 








2) 循环 时 间 长 开销 大 。 自 旋 CAS 如 果 长 时 间 不 成 功 ， 会 给 CPU 带 
来 非常 大 的 执行 开销 。 如 条 JVM 能 文 持 处 理 器 提供 的 pause 指 令 ， 那 么 
效率 会 有 一 定 的 提升 。pause 指 令 有 两 个 作用 : 第 一 ， 它 可 以 延迟 流水 
线 执行 指令 〈de-pipeline) ， 使 CPU 不 会 消耗 过 多 的 执行 资源 ， 延 迟 的 


时 间 取 决 于 具体 实现 的 版 本 ， 在 一 些 处 理 器 上 延迟 时 间 是 零 ， 第 二 ， 它 
可 以 避免 在 退出 循环 的 时 候 因 内 存 顺 序 冲突 (Memory Order Violation ) 
而 引起 CPU 流 水 线 被 清空 (CPU Pipeline Flush) ， 从 而 提高 CPU 的 执行 
效率 。 





3) 只 能 保证 一 个 共享 变量 的 原子 操作 。 当 对 一 个 共享 变量 执行 操 
作 时 ， 我 们 可 以 使 用 循环 CAS 的 方式 来 保证 原子 操作 ， 但 是 对 多 个 共享 
变量 操作 时 ， 循 环 CAS 就 无 法 保证 操作 的 原子 性 ， 这 个 时 候 就 可 以 用 
锁 。 还 有 一 个 取 巧 的 办 法 ， 就 是 把 多 个 共享 变量 合并 成 一 个 共享 变量 来 
操作 。 比 如 ， 有 两 个 共享 变量 i 二 2，j=a， 合 并 一 下 jj=2a， 然 后 用 CAS 来 
操作 jj。 从 Java 1.5 开 始 ，JDK 提 供 了 AtomicReference 类 来 保证 引用 对 象 
之 间 的 原子 性 ， 就 可 以 把 多 个 变量 放 在 一 个 对 象 里 来 进行 CAS 操 作 。 





(3) 使 用 锁 机 制 实现 原子 操作 


锁 机 制 保证 了 只 有 获得 锁 的 线程 才能 够 操作 锁定 的 内 存 区域 。JVM 
内 部 实现 了 很 多 种 锁 机 制 ， 有 侦 癌 锁 、 轻 量 级 锁 和 互 斥 锁 。 有 意思 的 是 
除了 偏 回 锁 ，JVM 实 现 锁 的 方式 都 用 了 循环 CAS， 即 当 一 个 线程 想 进 入 
同步 块 的 时 候 使 用 循环 CAS 的 方式 来 获取 锁 ， 当 筷 退 出 同步 块 的 时 候 使 
用 循环 CAS 释 放 锁 。 


2.4 本 章 小 结 


本 章 我 们 一 起 研究 了 volatile、synchronized 和 原子 操作 的 实现 原 
理 。Java 中 的 大 部 分 容器 和 框架 都 依赖 于 本 章 介 绍 的 volatile 和 原子 操作 
的 实现 原理 ， 了 解 这 些 原理 对 我 们 进行 并 发 编程 会 更 有 帮助 。 


第 3 章 ” Java 内存 模型 





Java 线 程 之 间 的 通信 对 程序 员 完 全 透明 ， 内 存 可 见 性 问题 很 容易 困 
扰 Java 程 序 员 ， 本 章 将 揭 开 Java 内 存 模 型 神秘 的 面纱 。 本 章 大致 分 4 部 
分 : Java 内 存 模型 的 基础 ， 主 要 介绍 内 存 模型 相关 的 基本 概念 ，Java 内 
存 模型 中 的 顺序 一 致 性 ， 主 要 介绍 重 排序 与 顺序 一 致 性 内 存 模型 ， 同 步 
原 语 ， 主 要 介绍 3 个 同步 原 语 (synchronized、volatile 和 final〉 的 内 存 语 
义 及 重 排序 规则 在 处 理 器 中 的 实现 ，Java 内 存 模型 的 设计 ， 主 要 介绍 
Java 内 存 模型 的 设计 原理 ， 及 其 与 处 理 器 内 存 模 型 和 顺序 一 致 性 内 存 模 


型 的 关系 。 











3.1 _ Java 内 存 模 型 的 基础 


3.1.1 并 友 编 程 模 型 的 两 个 关键 问题 


在 并 发 编程 中 ， 需 要 处 理 两 个 关键 问题 ， 线程 之 间 如 何 通信 及 线程 
之 间 如 何 同步 《这 里 的 线程 是 指 并 发 执行 的 活动 实体 ) 。 通 信和 是 指 线程 
之 间 以 何 种 机 制 来 交换 信息 。 在 命令 式 编 程 中 ， 线 程 之 间 的 通信 机 制 有 
两 种 : 共 至 内 存 和 消息 传递 。 





在 共享 内 存 的 并 发 模型 里 ， 线 程 之 间 共 享 程序 的 公共 状态 ， 通 过 
写 - 读 内 存 中 的 公共 状态 进行 隐 式 通信 。 在 消息 传递 的 并 发 模型 里 ， 线 
程 之 间 没 有 公共 状态 ， 线 程 之 间 必 须 通过 发 送 消息 来 显 式 进行 通信 。 





同步 是 指 程序 中 用 于 控制 不 同 线程 间 操 作 发 生 相 对 顺序 的 机 制 。 在 
共 孚 内 存 并 发 模型 里 ， 同 步 是 显 式 进行 的 。 程 序 员 必须 显 式 指定 茶 个 方 
法 或 茶 段 代码 需要 在 线程 之 间 互 斥 执行 。 在 消 轧 传递 的 并 发 模型 里 ， 由 
于 消息 的 有 发送 必 须 在 消 妃 的 接收 之 前 ， 因 此 同步 是 隐 式 进行 的 。 








Java 的 并 及 采用 的 是 共享 内 存 模型 ，Java 线 程 之 间 的 通信 息 是 隐 式 
进行 ， 整 个 通信 过 程 对 程序 员 完 全 透明 。 如 果 编 写 多 线程 程序 的 Java 程 
序 员 不 理解 隐 式 进行 的 线程 之 间 通 信 的 工作 机 制 ， 很 可 能 会 遇 到 各 种 奇 
怪 的 内 存 可 见 性 问题 。 

















3.1.2 ”Java 内 存 模型 的 抽象 结构 





在 Java 中 ， 所 有 实例 域 、 静 态 域 和 数组 元 又 都 存储 在 堆 内 存 中 ， 堆 
内 存在 线程 之 间 共 孚 〈 本 章 用 “共享 变量 "这 个 术语 代 指 实例 域 ， 静 态 域 
和 数组 元 素 ) 。 局 部 变量 (Local Variables)， 方 法 定义 参数 (Java 语 言 
规范 称 之 为 Formal Method Parameters) 和 异常 处 理 器 参数 (Exception 
Handler Parameters) 不 会 在 线程 之 间 共 享 ， 它 们 不 会 有 内 存 可 见 性 问 
题 ， 也 不 受 内 存 模型 的 影 啊 。 














Java 线 程 之 间 的 通信 由 Java 内 存 模型 〈 本 文 简称 为 JMM) 控制 ， 
JMM 诀 定 一 个 线程 对 共享 变量 的 写 入 何 时 对 另 一 个 线程 可 见 。 从 抽象 的 
角度 来 看 ，JMM 定 义 了 线程 和 主 内 存 之 间 的 抽象 关系 : 线程 之 间 的 共享 
变量 存储 在 主 内 存 (Main Memory) 中 ， 每 个 线程 都 有 一 个 私有 的 本 地 
内 存 (Local Memory) ， 本 地 内 存 中 存储 了 该 线程 以 读 / 写 共 享 变 量 的 
副本 。 本 地 内 存 是 JMM 的 一 个 抽象 概念 ， 并 不 真实 存在 。 它 涵盖 了 组 
存 、 写 缓冲 区 、 寄 存 器 以 及 其 他 的 硬件 和 编译 器 优化 。Java 内 存 模型 的 
抽象 示意 如 图 3-1 所 示 。 
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图 3-1 Java 内 存 模 型 的 抽象 结构 示意 图 





从 图 3-1 来 看 ， 如 果 线 程 A 与 线程 B 之 间 要 通信 的 话 ， 必 须要 经 历 下 


面 2 个 步骤 。 


1) 线程 A 把 本 地 内 存 A 中 更 新 过 的 共享 变量 刷新 到 主 内 存 中 去 。 





2) 线程 B 到 主 内 存 中 去 读 取 线 程 A 之 前 已 更 新 过 的 共 诗 变量 。 








下 面 通过 示意 图 〈 见 图 3-2) 来 说 明 这 两 个 步骤 。 
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图 3-2 ”线程 之 间 的 通信 图 








如 图 3-2 所 示 ， 本 地 内 存 A 和 本 地 内 存 B 由 主 内 存 中 共享 变量 x 的 副 
本 。 假 设 初 始 时 ， 这 3 个 内 存 中 的 x 值 都 为 0。 线 程 A 在 执行 时 ， 把 更 新 
后 的 x 值 〈 假 设 值 为 1〉 临时 存放 在 自己 的 本 地 内 存 A 中 。 当 线程 A 和 线 
程 B 需 要 通信 时 ， 线 程 A 首 先 会 把 自己 本 地 内 存 中 修改 后 的 x 值 刷新 到 主 
内 存 中 ， 此 时 主 内 存 中 的 x 值 变 为 了 1。 随 后 ， 线 程 B 到 主 内 存 中 去 读 取 
线程 A 更 新 后 的 x 值 ， 此 时 线程 B 的 本 地 内 存 的 x 值 也 变 为 了 1。 








从 整体 来 看 ， 这 两 个 步骤 实质 上 有 是 线程 A 在 同 线 程 B 发 送 消息 ， 而 


且 这 个 通信 过 程 必须 要 经 过 主 内 存 。JMM 通 过 控制 主 内 存 与 每 个 线程 的 
本 地 内 存 之 间 的 交互 ， 来 为 Java 程 序 员 提 供 内 存 可 见 性 保证 。 


3.1.3 ”从 源 代 码 到 指令 序列 的 重 排序 





在 执行 程序 时 ， 为 了 提高 性 能 ， 编 译 器 和 处 理 右 常常 会 对 指令 做 重 
排序 。 重 排序 分 3 种 类 型 。 


1) 编译 喜人 优化 的 重 排序 。 编 译 器 在 不 改变 单线 程 程序 语义 的 前 提 
下 ， 可 以 重新 安排 语句 的 执行 顺序 。 


2) 指令 级 并 行 的 重 排序 。 现 代 处 理 喜 采用 了 指令 级 并 行 技术 
(Instruction-Level Parallelism，ILP) 来 将 多 条 指令 重 县 执行 。 如 果 不 存 
在 数据 依赖 性 ， 处 理 器 可 以 改变 语句 对 应 机 器 指令 的 执行 顺序 。 











3) 内 存 系统 的 重 排序 。 由 于 处 理 器 使 用 缓存 和 读 / 写 缓冲 区 ， 这 使 
得 加 载 和 存储 操作 看 上 去 可 能 是 在 乱 序 执行 。 


从 Java 源 代码 到 最 终 实际 执行 的 指令 序列 ， 会 分 别 经 历 下 面 3 种 重 
排序 ， 如 图 3-3 所 示 。 








源 代 码 一 








1: 编译 器 | | 2: 指令 级 | ”| 3: 内 存 系 | | 最 终 执行 的 
优化 重 排序 并行 重 排序 统 重 排序 一 指令 序列 








图 3-3 ”从 源码 到 最 终 执 行 的 指令 序列 的 示意 图 





上 述 的 1 属于 编译 器 重 排序 ，2 和 3 属于 处 理 器 重 排序 。 这 些 重 排序 





可 能 会 导致 多 线程 程序 出 现 内 存 可 见 性 问题 。 对 于 编译 器 ，JMM 的 编译 
器 重 排序 规则 会 禁止 特定 类 型 的 编译 器 重 排序 〈 不 是 所 有 的 编译 器 重 排 
序 都 要 禁止 ) 。 对 于 处 理 器 重 排序 ，JMM 的 处 理 器 重 排 序 规则 会 要 求 
Java 编 译 器 在 生成 指令 序列 时 ， 插 入 特定 类 型 的 内 存 屏障 (Memory 
Barriers，Intel 称 之 为 Memory Fence) 指令 ， 通 过 内 存 屏 障 指令 来 禁止 特 
定 类 型 的 处 理 器 重 排序 。 














JMM 属 于 语言 级 的 内 存 模型 ， 它 确保 在 不 同 的 编译 器 和 不 同 的 处 理 
器 平台 之 上 ， 通 过 骏 止 特定 类 型 的 编译 井 重 排序 和 处 理 器 重 排序 ， 为 程 
序 员 提 供 一 致 的 内 存 可 见 性 保证 。 





3.1.4 并 发 编程 模型 的 分 类 


现代 的 处 理 器 使 用 写 缓 冲 区 临时 保存 同舟 存 写 入 的 数据 。 写 缓冲 区 
可 以 保证 指令 流水 线 持续 运行 ， 它 可 以 避免 由 于 处 理 需 停顿 下 来 等 竺 同 
内 存 写 入 数据 而 产生 的 延迟 。 同 时 ， 通 过 以 批 处 理 的 方式 刷新 写 缓冲 
区 ， 以 及 合并 写 缓冲 区 中 对 同一 内 存 地 址 的 多 次 写 ， 减 少 对 内 存 总 线 的 
占用 。 虽 然 写 缓冲 区 有 这 么 多 好 处 ， 但 每 个 处 理 器 上 的 写 缓冲 区 ， 仅 仅 
对 它 所 在 的 处 理 器 可 见 。 这 个 特性 会 对 内 存 操作 的 执行 顺序 产生 重要 的 
影响 : 处 理 器 对 内 存 的 读 / 写 操作 的 执行 顺序 ， 不 一 定 与 内 存 实际 发 生 
的 读 / 写 操作 顺序 一 致 ! 为 了 有 具体 说 明 ， 请 看 下 面 的 表 3-1。 








表 3-1 处 理 器 操作 内 存 的 执行 结果 


初始 状态 : a=b=0 
处 理 器 允许 执行 后 得 到 结果 : x=y=0 








Processor B 












假设 处 理 器 A 和 处 理 器 B 按 程序 的 顺序 并 行 执 行内 存 访 问 ， 最 终 可 
能 得 到 x=y=0 的 结果 。 具 体 的 原因 如 图 3-4 所 示 。 
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图 3-4 ”处 理 器 和 内 存 的 交互 


这 里 处 理 器 A 和 处 理 器 B 可 以 同时 把 共享 变量 写 入 自己 的 写 缓冲 区 
(A1，B1) ， 然 后 从 内 存 中 读 取 另 一 个 共享 变量 (A2，B2) ， 最 后 才 
把 自己 写 缓存 区 中 保存 的 脏 数 据 刷 新 到 内 存 中 〈A3，B3) 。 当 以 这 种 
时 序 执行 时 ， 程 序 就 可 以 得 到 x=y=0 的 结 








从 内 存 操作 实际 发 生 的 顺序 来 看 ， 直 到 处 理 器 A 执 行 A3 来 刷新 目 己 
的 写 缓 存 区 ， 写 操作 Al1 才 算 真 正 执行 了 。 虽 然 处 理 器 A 执 行内 存 操作 的 
顺序 为 : AL1-~A2， 但 内 存 操作 实际 发 生 的 顺序 却 是 A2~ Al。 此 时 ， 处 








理 器 A 的 内 存 操作 顺序 被 重 排序 了 〈 处 理 器 B 的 情况 和 处 理 器 A 一 样 ， 这 
里 就 不 蓝 述 了 ) 。 


这 里 的 关键 是 ， 由 于 写 缓冲 区 仪 对 自己 的 处 理事 可 见 ， 它 会 导致 处 
理 上 融 执行 内 存 操作 的 顺序 可 能 会 与 内 存 实际 的 操作 执行 顺序 不 一 至。 由 
于 现代 的 处 理 器 都 会 使 用 写 缓冲 区 ， 因 此 现代 的 处 理 需 都 会 多 许 对 写 - 
读 操 作 进 行 重 排序 。 


表 3-2 是 常见 处 理 右 允许 的 重 排序 类 型 的 列表 。 


表 3-2 处理 器 的 重 排序 规则 


Load-Load Load-Store Store-Store Store-Load 类 
处 理 器 EE eh 
N 】 


SPARC-TSO N 


PoweIPC 





注意 ， 表 3-2 单 元 格 中 的 “N?” 表 示 处 理 器 不 允许 两 个 操作 重 排 
序 , “Y” 表 示人 允许 重 排序 。 


从 表 3-2 我 们 可 以 看 出 : 常见 的 处 理 器 都 允许 Store-Load 重 排序 ， 锦 
见 的 处 理 器 都 不 允许 对 存在 数据 依赖 的 操作 做 重 排序 。sparc-TSO 和 X86 
拥有 相对 较 强 的 处 理 费 内 存 模型 ， 它 们 仪 允许 对 写 - 读 操 作 做 重 排 友 

(因为 它们 都 使 用 了 写 缓冲 区 ) 。 


© 注意 


.spatc-TSO 是 指 以 TSO (Total Store Order) 内 存 模 型 运行 时 sparc 处 
理 器 的 特性 。 


. 表 3-2 中 的 义 86 包 括 X64 及 AMD64。 


. 由 于 ARM 处 理 器 的 内 存 模型 与 PowetPC 处 理 器 的 内 存 模型 非常 类 


似 ， 本 文 将 忽略 它 。 
数据 依赖 性 后 文 会 专门 说 明 。 


为 了 保证 内 存 可 见 性 ，Java 编 译 器 在 生成 指令 序列 的 适当 位 置 会 插 
入 内 存 屏 障 指令 来 禁止 特定 类 型 的 处 理 器 重 排序 。JMM 把 内 存 屏障 指令 
分 为 4 类 ， 如 表 3-3 所 示 。 








表 3-3 内存 屏 障 类 型 表 
屏障 类 型 说 有 明 


LoadLoad Bairriers Loadl; LoadLoad: Load2 确保 Loadl 数据 的 装载 先 于 Load2 及 所 有 后 续 装 载 指令 
a E 的 装载 
确保 Storel 数据 对 其 他 处 理 器 可 见 ( 刷 新 到 内 存 ) 先 于 
StoreStore Barriers Storel:; StoreStore; Store2 a A RB 
sstsoesoeso | Store2 及 所 有 后 续 存储 指令 的 存储 
LoadStore Barriers Loadl: LoadStore; Store2 确保 Loadl 数据 装载 先 于 Store2 及 所 有 后 续 的 存储 指令 
| l b 刷新 到 内 存 


确保 Storel 数据 对 其 他 处 理 器 变 得 可 见 〈 指 刷新 到 内 存 ) 
先 于 Load2 及 所 有 后 续 装 载 指令 的 装载 。StoreLoad Barriers 
会 使 该 屏障 之 前 的 所 有 内 存 访问 指令 (存储 和 装载 指令 ) 完 
成 之 后 ， 才 执行 该 屏障 之 后 的 内 存 访问 指令 

















StoreLoad Barriers Storel: StoreLoad: Load2 





StoreLoad Barriers 是 一 个 “全 能 型 > 的 屏障 ， 它 同时 具有 其 他 3 个 屏障 
的 效果 。 现 代 的 多 处 理 器 大 多 支持 该 屏障 〈 其 他 类 型 的 屏障 不 一 定 被 所 


有 处 理 器 文 持 ) 。 执 行 该 屏障 开销 会 很 昂贵， 因为 当前 处 理 器 通常 要 把 
写 绥 冲 区 中 的 数据 全 部 刷新 到 内 存 中 〈Buffer Fully Flush) 。 





3.1.5 ”happens-before 人 简介 


从 JDK 5 开始 ，Java 使 用 新 的 JSR-133 内 存 模型 (除非 特别 说 明 ， 本 
文 针对 的 都 是 JSR-133 内 存 模型 ) 。JSR-133 使 用 happens-before 的 概念 来 
阐述 操作 之 间 的 内 存 可 见 性 。 在 JMM 中 ， 如 果 一 个 操作 执行 的 结果 需要 
对 另 一 个 操作 可 见 ， 那 么 这 两 个 操作 之 间 必 须要 存在 happens-before 关 
系 。 这 里 提 到 的 两 个 操作 既 可 以 是 在 一 个 线程 之 内 ， 也 可 以 是 在 不 同 线 
程 之 间 。 





与 程序 员 密 切 相 关 的 happens-before 规 则 如 下 。 


程序 顺序 规则 : 一 个 线程 中 的 每 个 操作 ，happens-before 于 该 线程 
中 的 任意 后 续 操 作 。 


监视 器 锁 规 则 : 对 一 个 锁 的 解锁 ，happens-before 于 随后 对 这 个 锁 


的 加 锁 。 


. volatile 变 量规 则 : 对 一 个 volatile 域 的 写 ，happens-before 于 任意 后 


续 对 这 个 volatile 域 的 读 。 


` 传递 性 : 如 果 A happens-before B， 且 B happens-before C， 那 么 A 


happens-befote C。 


人 @ 注意 两 个 操作 之 间 具 有 happens_ before 关系 ， 并 不 意味 着 前 一 
个 操作 必须 要 在 后 一 个 操作 之 前 执行 ! happens-before 仅 仅 要 求 前 一 个 操 
作 ( 执 行 的 结果 ) 对 后 一 个 操作 可 见 ， 且 前 一 个 操作 按 顺 序 排 在 第 二 个 
操作 之 前 (the first is visible to and ordered befote the second) 。happens- 
before 的 定义 很 微妙 ， 后 文 会 具体 说 明 happens-before 为 什么 要 这 么 定 


义 。 


happens-before 与 JMM 的 关系 如 图 3-5 所 示 。 
































程序 员 ) 
happens-before happens-before happens-before | pr 
规 见 规 见 规 见 ee 
轩 PR 有 的 视图 
禁止 某 种 禁止 某 种 禁止 某 种 禁止 某 种 JMM 
类 型 的 编译 类 型 的 编译 类 型 的 处 理 类 型 的 处 理 的 实现 
需 重 排序 需 重 排序 需 重 排序 需 重 排序 
| | | | JMM 
编译 器 重 编译 器 重 处 理 器 重 处 理 器 重 二 可 的 
排序 规则 排序 规则 排序 规则 排序 规则 规则 





























图 3-5 “happens-befotre 与 JMM 的 关系 


如 图 3-5 所 示 ， 一 个 happens-before 规 则 对 应 于 一 个 或 多 个 编译 器 和 
处 理 占 重 排 序 规划 。 对 于 Java 程 序 员 来 说 ，happens-before 规 则 简单 易 
懂 ， 它 避免 Java 程 序 员 为 了 理解 JMM 提 供 的 内 存 可 见 性 保证 而 去 学 习 复 
杂 的 重 排 序 规则 以 及 这 些 规 则 的 具体 实现 方法 。 





3.2 重 排序 





重 排序 是 指 编译 器 和 处 理 需 为 了 优化 程序 性 能 而 对 指令 序列 进行 重 
新 排序 的 一 种 手段 。 


3.2.1 数据 依赖 性 


如 果 两 个 操作 访问 同一 个 变量 ， 且 这 两 个 操作 中 有 一 个 为 写 操作 ， 
此 时 这 两 个 操作 之 间 就 存在 数据 依赖 性 。 数 据 依赖 分 为 下 列 3 种 类 型 ， 
如 表 3-4 所 示 。 


表 3-4 数据 依赖 类 型 表 





名 称 代码 示例 说 明 
12 [二 十 a= ls 2 P< 下 .~ 一 -vv .brs 
与 后 读 写 一 个 变量 之 后 ， 再 读 这 个 位 置 
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上 面 3 种 情况 ， 只 要 重 排 序 两 个 操作 的 执行 顺序 ， 程 序 的 执行 结 
就 会 被 改变 。 


前 面 提 到 过 ， 纺 译 需 和 处 理 喜 可 能 会 对 操作 做 重 排序 。 编 译 器 和 处 
理 需 在 重 排序 时 ， 会 遵守 数据 依赖 性 ， 编 译 器 和 处 理 圳 不 会 改变 存在 数 
气 依 赖 关 系 的 两 个 操作 的 执行 顺序 。 


这 里 所 说 的 数据 依赖 性 仅 针对 单个 处 理 器 中 执行 的 指令 序列 和 单个 
线程 中 执行 的 操作 ， 不 同 处 理 圳 之 间 和 不 同 线程 之 间 的 数据 依赖 性 不 被 
编译 器 和 处 理 器 考虑 。 





3.2.2 ”as-if-serial 语 义 


as-if-serial 语 义 的 意思 是 : 不 管 怎 么 重 排序 〈 编 译 器 和 处 理 器 为 了 
提高 并 行 度 ) ，“ 单 线程 ) 程序 的 执行 结果 不 能 被 改变 。 编 诺 器 、 
runtime 和 处 理 器 都 必须 遵守 as-if-serial 语 义 。 


为 了 遵守 as-if-serial 语 义 ， 编 译 器 和 处 理 器 不 会 对 存在 数据 依赖 关 
系 的 操作 做 重 排 序 ， 因 为 这 种 重 排序 会 改变 执行 结果 。 但 是 ， 如 果 操 作 
之 间 不 存在 数据 依赖 关系 ， 这 些 操作 束 可 能 被 编译 器 和 处 理 喜 重 排 序 。 
为 了 具体 说 明 ， 请 看 下 面 计 算 圆 面积 的 代码 示例 。 








double pi = 3.14; //A 
double r = 1.0; // B 
double area = pi * r * r; //C 


上 面 3 个 操作 的 数据 依赖 关系 如 图 3-6 所 示 。 


图 3-6 3 个 操作 之 间 的 依赖 关系 


如 图 3-6 所 示 ，A 和 C 之 间 存 在 数据 依赖 关系 ， 同 时 B 和 C 之 间 也 存在 
数据 依赖 关系 。 因 此 在 最 终 执行 的 指令 序列 中 ，C 不 能 被 重 排序 到 A 和 B 
的 前 面 〈《C 排 到 A 和 B 的 前 面 ， 程 序 的 结果 将 会 被 改变 ) 。 但 A 和 B 之 间 
没有 数据 依赖 关系 ， 编 译 器 和 处 理 器 可 以 重 排序 A 和 B 之 间 的 执行 顺 
序 。 图 3-7 是 该 程序 的 两 种 执行 顺序 。 





按 程序 顺序 的 执行 结果 : 
area = 3.14 


pg SR 六 we \ 序 » 当 行 结 . 
\ 4 \ / \ / area = 3.14< 


图 3-7 程序 的 两 种 执行 顺序 








as-if-serial 语 义 把 单线 程 程序 保护 了 起 来 ， 遵 守 as-if-serial 语 义 的 编 


译 器 、runtime 和 处 理 器 共同 为 编写 单线 程 程序 的 程序 员 创建 了 一 个 纪 


觉 ， 单 线程 程序 是 按 程 序 的 顺序 来 执行 的 。as-if-serial 语 义 使 单线 程 程 
序 员 无 需 担 心 重 排序 会 干扰 他 们 ， 也 无 需 担 心 内 存 可 见 性 问题 。 


< 














3.2.3 ”程序 顺序 规则 








根据 happens-before 的 程序 顺序 规则 ， 上 面 计 算 圆 的 面积 的 示例 代码 
存在 3 个 happens-before 关 系 。 


1) A happens-before B。 
2) B happens-before C。 
3) A happens-before C。 


这 里 的 第 3 个 happens-before 关 系 ， 是 根据 happens-before 的 传递 性 推 
导出 来 的 。 


这 里 A happens-before B， 但 实际 执行 时 B 却 可 以 排 在 A 之 前 执行 

(看 上 面 的 重 排序 后 的 执行 顺序 ) 。 如 果 A happens-before B，JMM 并 
不 要 求 A 一 定 要 在 B 之 前 执行 。JMM 仅 仅 要 求 前 一 个 操作 〈 执 行 的 结 
果 ) 对 后 一 个 操作 可 见 ， 且 前 一 个 操作 按 顺序 排 在 第 二 个 操作 之 前 。 这 
里 操作 A 的 执行 结果 不 需要 对 操作 B 可 见 ， 而 且 重 排序 操作 A 和 操作 B 后 
的 执行 结果 ， 与 操作 A 和 操作 B 按 happens-before 顺 序 执行 的 结果 一 致 。 
在 这 种 情况 下 ，JMM 会 认为 这 种 重 排 序 并 不 非法 (not illegal) ，JMM 
允许 这 种 重 排 序 。 











在 计算 机 中 ， 软 件 技术 和 硬件 技术 有 一 个 共同 的 目标 : 在 不 改变 程 
序 执行 结果 的 前 提 下 ， 尽 可 能 提高 并 行 度 。 编 译 器 和 处 理 器 遵从 这 一 目 
标 ， 从 happens-before 的 定义 我 们 可 以 看 出 ，JMM 同 样 遵 从 这 一 目标 。 





3.2.4 重 排序 对 多 线程 的 影响 





现在 让 我 们 来 看 看 ， 重 排序 是 否 会 改变 多 线程 程序 的 执行 结果 。 请 
看 下 面 的 示例 代码 。 


class ReorderExample { 
/ 


boolean flag = false; 
public void writer() { 


a= 1; //1 
flag = true; // 2 
} 
Public void reader() { 
if (f?1ag) { // 3 
int i = a* a; // 4 





flag 变 量 是 个 标记 ， 用 来 标识 变量 a 是 否 已 被 写 入 。 这 里 假设 有 两 个 
线程 A 和 B，A 首 先 执 行 writer() 方 法 ， 随 后 B 线 程 接着 执行 reader() 方 法 。 
线程 B 在 执行 操作 4 时 ， 能 否 看 到 线程 A 在 操作 1 对 共享 变量 a 的 写 入 呢 ? 











答 采 是 ; 不 一 定 能 看 到 。 


由 于 操作 1 和 操作 2 没有 数据 依赖 关系 ， 编 译 器 和 处 理 右 可 以 对 这 两 
个 操作 重 排 友 ， 同 样 ， 操 作 3 和 操作 4 没有 数据 依赖 关系 ， 编 译 器 和 处 理 
虱 也 可 以 对 这 两 个 操作 重 排序 。 让 我 们 先 来 看 看 ， 当 操作 1 和 操作 2 重 排 
序 时 ， 可 能 会 产生 什么 效果 ? 请 看 下 面 的 程序 执行 时 序 图 ， 如 图 3-8 所 


人 钞 。 


线程 A 线程 B 


flag = true; 


if (flag) 


时 间 





a=1: 


图 3-8 程序 执行 时 序 图 


如 图 3-8 所 示 ， 操 作 1 和 操作 2 做 了 重 排序 。 程 序 执行 时 ， 线 程 A 首 移 
写 标 记 变 量 fag， 随 后 线程 B 读 这 个 变量 。 由 于 条 件 判断 为 真 ， 线 程 B 将 
读 取 变 量 a。 此 时 ， 变 量 a 还 没有 被 线程 A 写 入 ， 在 这 里 多 线程 程序 的 语 
义 被 重 排序 破坏 了 ! 


馈 注意 “本文 统一 用 应 箭 线 标 识 错误 的 读 操作 ， 用 实 箭 线 标识 正 
确 的 读 操作 。 


下 面 再 让 我 们 看 看 ， 当 操作 3 和 操作 4 重 排序 时 会 产生 什么 效果 借 
助 这 个 重 排 夺 ， 可 以 顺便 说 明 控制 依赖 性 ) 。 下 面 是 操作 3 和 操作 4 重 排 
序 后 ， 程 友 执 行 的 时 序 图 ， 如 图 3-9 所 示 。 


线 程 A 线 程 B 


temp=a*a; 





a= 1: 本 
取 a， 猜 


时 间 测 执行 实 


flag = true; 质 上 对 操 


作 做 了 重 


i 排序 。 
if (flag) 


| int i = temp; 














图 3-9 ”程序 的 执行 时 序 图 


在 程序 中 ， 操 作 3 和 操作 4 存在 控制 依赖 关系 。 当 代码 中 存在 控制 依 
赖 性 时 ， 会 影响 指令 序列 执行 的 并 行 度 。 为 此 ， 编 译 器 和 处 理 器 会 采用 
猜测 〈Speculation) 执行 来 克服 控制 相关 性 对 并 行 度 的 影响 。 以 处 理 器 
的 猜测 执行 为 例 ， 执 行 线程 B 的 处 理 器 可 以 提前 读 取 并 计算 ara， 然 后 把 
计算 结果 临时 保存 到 一 个 名 为 重 排序 缓冲 〈Reorder Buffer，ROB ) 的 便 
件 缓存 中 。 当 操作 3 的 条 件 判 断 为 真 时 ， 就 把 该 计算 结果 写 入 变量 i 中 。 








从 图 3-9 中 我 们 可 以 看 出 ， 猜 测 执行 实质 上 对 操作 3 和 4 做 了 重 排 
序 。 重 排序 在 这 里 破坏 了 多 线程 程序 的 语义 ! 





在 单线 程 程序 中 ， 对 存在 控制 依赖 的 操作 重 排 序 ， 不 会 改变 执行 结 
朵 (这 也 是 as-if-serial 语 义 允 许 对 存在 控制 依赖 的 操作 做 重 排序 的 原 
因 )〉; 但 在 多 线程 程序 中 ， 对 存在 控制 依赖 的 操作 重 排 序 ， 可 能 会 改变 
程序 的 执行 结 


3.3 ”顺序 一 致 性 


顺序 一 致 性 内 存 模型 是 一 个 理论 参考 模型 ， 在 设计 的 时 候 ， 处 理 器 
的 内 存 模型 和 编程 语言 的 内 存 模型 都 会 以 顺序 一 致 性 内 存 模型 作为 参 


申 。 


3.3.1 数据 竞争 与 顺序 一 致 性 

当 程序 未 正确 同步 时 ， 就 可 能 会 存在 数据 竞争 。Java 内 存 模型 规范 
对 数据 竞争 的 定义 如 下 。 

在 一 个 线程 中 写 一 个 变量 ， 

在 另 一 个 线程 读 同一 个 变量 ， 

而 且 写 和 读 没 有 通过 同步 来 排序 。 


当代 码 中 包含 数据 竞争 时 ， 程 序 的 执行 往往 产生 违反 直觉 的 结 
〈 前 一 章 的 示例 正 是 如 此 ) 。 如 果 一 个 多 线程 程序 能 正确 同步 ， 这 个 程 
序 将 是 一 个 没有 数据 竞争 的 程序 。 





JMM 对 正确 同步 的 多 线程 程序 的 内 存 一 致 性 做 了 如 下 保证 。 





如 果 程 序 是 正确 同步 的 ， 程 序 的 执行 将 具有 顺序 一 致 性 
(Sequentially Consistent〉 一 一 即 程序 的 执行 结果 与 该 程序 在 顺序 一 致 
性 内 存 模型 中 的 执行 结果 相同 。 马 上 我 们 就 会 看 到 ， 这 对 于 程序 员 来 说 
是 一 个 极 强 的 保证 。 这 里 的 同步 是 指 广义 上 的 同步 ， 包 括 对 常用 同步 原 

语 〈synchronized、volatile 和 final) 的 正确 使 用 。 





3.3.2 ”顺序 一 致 性 内 存 模型 


顺序 一 致 性 内 存 模型 是 一 个 被 计算 机 科学 家 理想 化 了 的 理论 参考 模 
型 ， 它 为 程序 员 提 供 了 极 强 的 内 存 可 见 性 保证 。 顺 序 一 致 性 内 存 模型 有 
两 大 特性 。 


1) 一 个 线程 中 的 所 有 操作 必须 按照 程序 的 顺序 来 执行 。 





2) 《不管 程序 是 人 否 同步 ) 所 有 线程 都 只 能 看 到 一 个 单一 的 操作 执 
行 顺 序 。 在 顺序 一 致 性 内 存 模型 中 ， 每 个 操作 都 必须 原子 执行 且 立 刻 对 
所 有 线程 可 见 。 











顺序 一 致 性 内 存 模型 为 程序 员 提 供 的 视图 如 图 3-10 所 示 。 


全 
NA 


内 存 





图 3-10 ”顺序 一 致 性 内 存 模 型 的 视图 


在 概念 上 ， 顺 序 一 致 性 模型 有 一 个 单一 的 全 局 内 存 ， 
一 个 左右 摆动 的 开关 可 以 连接 到 任意 一 个 线程 ， 


这 个 内 存 通过 
同时 每 一 个 线程 必须 按 
照 程序 的 顺序 来 执行 内 存 读 / 写 操作 。 从 上 面 的 示意 图 可 以 看 出 ， 在 任 

意 时间 点 最 多 内 能 有 一 个 线程 可 以 连接 到 内 存 。 当 多 个 线程 并 发 执行 

时 ， 图 中 的 开关 装置 能 把 所 有 线程 的 所 有 内 存 读 / 写 操作 串 行 化 〈 即 在 

顺序 一 致 性 模型 中 ， 所 有 操作 之 间 具 有 全 序 关 系 ) 。 

















为 了 更 好 进行 理解 ， 下 面 通 过 两 个 示意 图 来 对 顺序 一 致 性 模型 的 特 
性 做 进一步 的 说 明 。 


假设 有 两 个 线程 A 和 B 并 发 执行 。 其 中 A 线程 有 3 个 操作 ， 它 们 在 程 
序 中 的 顺序 是 : A1 -A2 A3 。B 线 程 也 有 3 个 操作 ， 它 们 在 程序 中 的 顺 


序 是 : Bl1 ,B22 PB3。 





假设 这 两 个 线程 使 用 监视 器 锁 来 正确 同步 : A 线程 的 3 个 操作 执行 
后 释放 监视 器 锁 ， 随 后 B 线 程 获取 同一 个 监视 融 锁 。 那 么 程序 在 顺序 一 
致 性 模型 中 的 执行 效果 将 如 图 3-11 所 示 。 


线程 A 的 et a , 
程序 顺序 : ， ”操作 的 执行 整体 上 有 序 ， 且 两 


a) Co | 个 线程 都 只 能 看 到 这 个 执行 顺序 。 


OO 
程序 顺序 : . 本 八 人 2 





(a) 


Re 


' 线程 A 的 程 . 线程 B 的 程 | 
| 序 顺序 不 变 | ， 序 顺序 不 变 


图 3-11 顺序 一 致 性 模型 的 一 种 执行 效果 


现在 我 们 再 假设 这 两 个 线程 没有 做 同步 ， 下 面 是 这 个 未 同步 程序 在 
顺序 一 致 性 模型 中 的 执行 示意 图 ， 如 图 3-12 所 示 。 


线程 A 的 ER 
程序 顺序 : ' 操作 的 执行 整体 上 无 序 ， 但 两 个 ， 
,线程 都 只 能 看 到 这 个 执行 顺序 


a a a) ~\ be 由 - Sy oO | 

wa OO 
程序 顺序 : 
全 Cm ) Cm) 有 gt 


i 有 ， 线程 B 的 程 
上 序 顺 序 不 变 1 序 顺序 不 变 





图 3-12 ”顺序 一 致 性 模型 中 的 另 一 种 执行 效果 





未 同步 程序 在 顺序 一 致 性 模型 中 虽然 整体 执行 顺序 是 无 序 的 ， 但 所 
有 线程 都 只 能 看 到 一 个 一 致 的 整体 执行 顺序 。 以 上 图 为 例 ， 线 程 A 和 B 
看 到 的 执行 顺序 都 是 ， Bl Al- A2-B2-A3-,B3。 之 所 以 能 得 到 这 个 
保证 是 因为 顺序 一 致 性 内 存 模 型 中 的 每 个 操作 必须 立即 对 任意 线程 可 
见 。 











但 是 ， 在 JMM 中 就 没有 这 个 保证 。 未 同步 程序 在 JMM 中 不 但 整体 
的 执行 顺序 是 无 序 的 ， 而 且 所 有 线程 看 到 的 操作 执行 顺序 也 可 能 不 一 
致 。 比 如 ， 在 当前 线程 把 写 过 的 数据 缓存 在 本 地 内 存 中 ， 在 没有 刷新 到 
主 内 存 之 前 ， 这 个 写 操作 仅 对 当前 线程 可 见 ， 从 其 他 线程 的 角度 来 观 
察 ， 会 认为 这 个 与 操作 根本 没有 被 当前 线程 执行 。 只 有 当前 线程 把 本 地 











内 存 中 写 过 的 数据 刷新 到 主 内 存 之 后 ， 这 个 写 操作 才能 对 其 他 线程 可 
见 。 在 这 种 情况 下 ， 当 前 线程 和 其 他 线程 看 到 的 操作 执行 顺序 将 不 一 
致 。 


3.3.3 ”同步 程序 的 顺序 一 致 性 效果 


下 面 ， 对 前 面 的 示例 程序 ReorderExample 用 锁 来 同步 ， 看 看 正确 同 
步 的 程序 如 何 具 有 顺序 一 致 性 。 


请 看 下 面 的 示例 代码 。 





class SynchronizedExample { 
boolean flag = = false; 
Ps 0 void writer() { // 获取 锁 


ee = true,; 
// 释放 锁 
public synchronized void reader() { // 获取 锁 
if (flag) { 
int i = a; 
} // 释放 锁 





在 上 面 示例 代码 中 ， 假 设 A 线 程 执行 writer(0 方 法 后 ，B 线 程 执行 
reader() 方 法 。 这 是 一 个 正确 同步 的 多 线程 程序 。 根 据 JMM 规 范 ， 该 程 
序 的 执行 结果 将 与 该 程序 在 顺序 一 致 性 模型 中 的 执行 结果 相同 。 下 面 是 
该 程序 在 两 个 内 存 模型 中 的 执行 时 序 对 比 图 ， 如 图 3-13 所 示 。 








顺序 一 致 性 模型 中 ， 所 有 操作 完全 按 程 序 的 顺序 串 行 执行 。 而 在 
JMM 中 ， 临 界 区 内 的 代码 可 以 重 排 序 〈 但 JMM 不 允许 临界 区 内 的 代 
码 “ 逸 出 ?到 临界 区 之 外 ， 那 样 会 破坏 监视 器 的 语义 ) 。JMM 会 在 退出 临 
界 区 和 进入 临界 区 这 两 个 关键 时 间 点 做 一 些 特别 处 理 ， 使 得 线程 在 这 两 





个 时 间 扣 具有 与 顺序 一 致 性 模型 相同 的 内 存 视 图 (具体 细 市 后 文 会 说 
明 ) 。 虽 然 线 程 A 在 临界 区 内 做 了 重 排序 ， 但 由 于 监视 器 互 斥 执行 的 特 
性 ， 这 里 的 线程 B 根 本 无 法 “观察 ?到 线程 A 在 临界 区 内 的 重 排序 。 这 种 
重 排序 既 提 高 了 执行 效率 ， 又 疫 有 改变 程序 的 执行 结 



































在 JMM 在 顺序 一 至 
中 的 执行 性 模型 中 的 
执行 
A 获取 锁 A 获取 锁 
i | 本 效 按 程 序 「| a=1 | 
内 可 以 顺序 
| a= 1; 重 排序 执行 flag = true; 














时 间 要 
A 释放 锁 | 人 A 释放 策 | 

B 获取 锁 B 获取 锁 

int i= a: | 临界 区 按 程 序 if (flag) 





























内 可 以 顺序 
重 排序 执行 int i= a: 











if (flag) 














B 释放 锁 | B 释放 锁 








图 3-13 ”两 个 内 存 模型 中 的 执行 时 序 对 比 图 


从 这 里 我 们 可 以 看 到 ，JMM 在 具体 实现 上 的 基本 方针 为 : 在 不 改变 
《正确 同步 的 ) 程序 执行 结果 的 前 提 下 ， 尽 可 能 地 为 编译 器 和 处 理 露 的 


优化 打开 方便 之 门 。 


3.3.4 未 同步 程序 的 执行 特性 











对 于 未 同步 或 未 正确 同步 的 多 线程 程序 ，JMM 只 提供 最 小 安全 性 : 
线程 执行 时 读 取 到 的 值 ， 要 么 是 之 前 某 个 线程 号 入 的 值 ， 要 么 是 默认 值 
0，Nul，False) ，JMM 保 证 线程 读 操 作 读 取 到 的 值 不 会 无 中 生 有 
(Out Of Thin Air) 的 冒 出 来 。 为 了 实现 最 小 安全 性 ，JVM 在 堆 上 分 配 
对 象 时 ， 首 先 会 对 内 存 空间 进行 清 零 ， 然 后 才 会 在 上 面 分 配对 象 (JVM 
内 部 会 同步 这 两 个 操作 ) 。 因 此 ， 在 已 清 零 的 内 存 空 间 (Pre-zeroed 
Memory) 分 配对 象 时 ， 域 的 默认 初始 化 已 经 完成 了 。 








JMM 不 保证 未 同步 程序 的 执行 结果 与 该 程序 在 顺序 一 致 性 模型 中 的 
执行 结果 一 致 。 因 为 如 条 想 要 保证 执行 结果 一 致 ，JMM 需 要 蔡 止 大 量 的 
处 理 器 和 编译 颖 的 优化 ， 这 对 程序 的 执行 性 能 会 产生 很 大 的 影响 。 而 且 
未 同步 程序 在 顺序 一 致 性 模型 中 执行 时 ， 整 体 是 无 序 的 ， 其 执行 结果 往 
往 无 法 预知 。 而 且 ， 保 证 未 同步 程序 在 这 两 个 模型 中 的 执行 结果 一 致 没 
什么 意义 。 


未 同步 程序 在 JMM 中 的 执行 时 ， 整 体 上 是 无 序 的， 其 执行 结果 无 法 
预知 。 未 同步 程序 在 两 个 模型 中 的 执行 特性 有 如 下 几 个 差异 。 





1) 顺序 一 致 性 模型 保证 单线 程 内 的 操作 会 按 程 序 的 顺序 执行 ， 而 
JMM 不 保证 单线 程 内 的 操作 会 按 程序 的 顺序 执行 (比如 上 面 正确 同步 的 


多 线程 程序 在 临界 区 内 的 重 排序 ) 。 这 一 点 前 面 已 经 讲 过 了 ， 这 里 就 不 
再 资 述 


) 顺序 一 致 性 模型 保证 所 有 线程 只 能 看 到 一 怪 的 操作 执行 顺序 ， 
而 JMM 不 保证 所 有 线程 能 看 到 一 致 的 操作 执行 顺序 。 这 一 点 前 面 也 已 经 
讲 过 ， 这 里 就 不 再 资 述 


3) JMM 不 保证 对 64 位 的 long 型 和 double 型 变量 的 写 操作 具有 原子 
性 ， 而 顺序 一 致 性 模型 保证 对 所 有 的 内 存 读 / 写 操作 都 具有 原子 性 。 





第 3 个 差异 与 处 理 器 总 线 的 工作 机 制 密切 相关 。 在 计算 机 中 ， 数 据 

过 总 线 在 处 理 器 和 内 存 之 间 传 递 。 每 次 处 理 器 和 内 存 之 间 的 数据 传递 
都 是 通过 一 系列 步骤 来 完成 的 ， 这 一 系列 步骤 称 之 为 总 线 事 务 〈Bus 
Transaction) 。 总 线 事务 包括 读 事 务 〈Read Transaction) 和 写 事务 
(Write Transaction) 。 读 事务 从 内 存 传 送 数据 到 处 理 器 ， 写 事务 从 处 
理 器 传送 数据 到 内 存 ， 每 个 事务 会 读 / 写 内 存 中 一 个 或 多 个 物理 上 连续 
的 字 。 这 里 的 关键 是 ， 总 线 会 同步 试图 并 发 使 用 总 线 的 事务 。 在 一 个 处 
理 器 执行 总 线 事务 期 间 ， 总 线 会 禁止 其 他 的 处 理 器 和 IO 设备 执行 内 存 
的 读 / 写 。 下 面 ， 让 我 们 通过 一 个 示意 图 来 说 明 总 线 的 工作 机 制 ， 如 图 3- 
14 所 示 。 
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图 3-14 ”总 线 的 工作 机 制 








由 图 可 知 ， 假 设 处 理 器 A，B 和 C 同 时 向 总 线 发 起 总 线 事务 ， 这 时 总 
线 仲裁 (Bus Arbitration) 会 对 竞争 做 出 裁决 ， 这 里 假设 总 线 在 仲裁 后 
判定 处 理 器 A 在 竞争 中 获胜 (总 线 仲裁 会 确保 所 有 处 理 器 都 能 公平 的 访 
问 内 存 )。 此 时 处 理 器 A 继续 它 的 总 线 事 务 ， 而 其 他 两 个 处 理 器 则 要 等 





竺 处 理 器 A 的 总 线 事务 完成 后 才能 再 次 执行 内 存 访问 。 假 设 在 处 理 器 A 
执行 总 线 事务 期 间 《〈 不 管 这 个 总 线 事务 是 读 事务 还 是 写 事务 ) ， 处 理 絮 
D 问 总 线 发 起 了 总 线 事务 ， 此 时 处 理 器 D 的 请 求 会 被 总 线 蔡 止 。 











忆 线 的 这 些 工作 机 制 可 以 把 所 有 处 理 右 对 内 存 的 访问 以 串 行 化 的 方 
式 来 执行 。 在 任意 时 间 点 ， 最 多 只 能 有 一 个 处 理 器 可 以 访问 内 存 。 这 个 
特性 确保 了 单个 总 线 事务 之 中 的 内 存 读 / 写 操作 具有 原子 性 。 








在 一 些 32 位 的 处 理 器 上 ， 如 果 要 求 对 64 位 数据 的 写 操 作 具 有 原子 
性 ， 会 有 比较 大 的 开销 。 为 了 照顾 这 种 处 理 器 ，Java 语 言 规范 鼓励 但 不 
强求 JVM 对 64 位 的 long 型 变量 和 double 型 变量 的 写 操作 具有 原子 性 。 当 
JVM 在 这 种 处 理 器 上 运行 时 ， 可 能 会 把 一 个 64 位 long/double 型 变量 的 写 
操作 拆 分 为 两 个 32 位 的 写 操作 来 执行 。 这 两 个 32 位 的 写 操作 可 能 会 被 分 
配 到 不 同 的 总 线 事务 中 执行 ， 此 时 对 这 个 64 位 变量 的 写 操作 将 不 具有 原 
sg 


当 单 个 内 存 操 作 不 具有 原子 性 时 ， 可 能 会 产生 意 想 不 到 后 果 。 请 看 
示意 图 ， 如 图 3-15 所 示 。 
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写 事务 1: 
写 long 型 变量 的 高 32 位 | 





读 long 型 变量 的 高 32 位 











写 事 务 2: | 
写 long 型 变量 的 低 32 位 | 








图 3-15 ”总 线 事 务 执行 的 时 序 图 


如 上 图 所 示 ， 假 设 处 理 器 A 写 一 个 long 型 变量 ， 同 时 人 处理 器 B 要 读 这 
个 long 型 变量 。 处 理 絮 A 中 64 位 的 写 操作 被 拆 分 为 两 个 32 位 的 写 操作 ， 
且 这 两 个 32 位 的 写 操作 被 分 配 到 不 同 的 写 事务 中 执行 。 同 时 ， 处 理 器 B 
中 64 位 的 读 操 作 被 分 配 到 单个 的 读 事务 中 执行 。 当 处 理 器 A 和 B 按 上 图 
的 时 序 来 执行 时 ， 处 理 器 B 将 看 到 仅仅 被 处 理 器 A“ 写 了 一 半 ” 的 无 效 
值 。 





注意 ， 在 JSR-133 之 前 的 旧 内 存 模型 中 ， 一 个 64 位 long/double 型 变 
量 的 读 / 写 操作 可 以 被 拆 分 为 两 个 32 位 的 读 / 写 操作 来 执行 。 从 JSR-133 内 
存 模型 开始 ( 即 从 JDK5 开 始 ) ， 仪 仅 只 允许 把 一 个 64 位 long/double 型 变 
量 的 写 操 作 拆 分 为 两 个 32 位 的 写 操作 来 执行 ， 任 意 的 读 操作 在 JSR-133 


中 都 必须 具有 原子 性 〈 即 任意 读 操 作 必 须要 在 单个 读 事务 中 执行 ) 。 


3.4 ” volatile 的 内 存 语 义 


当 声 明 共 享 变 量 为 volatile 后 ， 对 这 个 变量 的 读 / 写 将 会 很 特别 。 为 
了 揭 开 volatile 的 神秘 面纱 ， 下 面 将 介绍 volatile 的 内 存 语 义 及 volatile 内 存 
语义 的 实现 。 


3.4.1 volatile 的 特性 


理解 volatile 特 性 的 一 个 好 方法 是 把 对 volatile 变 量 的 单个 读 / 写 ， 看 
成 是 使 用 同一 个 锁 对 这 些 单个 读 / 写 操作 做 了 同步 。 下 面 通过 具体 的 示 
例 来 说 明 ， 示 例 代 码 如 下 。 








class VolatileFeaturesExample { 





volatile long v1 = QL; // 使 用 volatile 声 明 64 位 的 long 型 变量 
public void set(long 1) { 
VE := ; // 单个 volatile 变 量 的 写 





public void getAndIncrement () { 
V1++; // 复合 (多 个 ) volatile 变 量 的 读 / 写 





} 
public long get() { 
return v1; // 单个 volatile 变 量 的 读 








假设 有 多 个 线程 分 别 调用 上 面 程序 的 3 个 方法 ， 这 个 程序 在 语义 上 
和 下 面 程序 等 价 。 





Class VolatileFeaturesExample { 















































































































































long v1 = QL; // 64 位 的 long 型 普通 变量 

public synchronized void set(long 1) { // 对 单个 的 普通 变量 的 写 用 同一 个 锁 同步 
vl = 1; 

} 

public void getAndIncrement () { // 普通 方法 调用 
long temp = get(); // 调用 已 同步 的 读 方法 
temp += 1L; // 普通 写 操作 
set(temp ) ; // 调用 已 同步 的 写 方法 

} 

public synchronized long get() { // 对 单个 的 普通 变量 的 读 用 同一 个 锁 同步 
return vi1; 








如 上 面 示 例 程 序 所 示 ， 一 个 volatile 变 量 的 单个 读 / 写 操作 ， 与 一 个 


普通 变量 的 读 / 写 操作 都 是 使 用 同一 个 锁 来 同步 ， 它 们 之 间 的 执行 效果 
日 同 。 


St 





锁 的 happens-before 规 则 保证 释放 锁 和 获取 锁 的 两 个 线程 之 间 的 内 存 
可 见 性 ， 这 意味 着 对 一 个 volatile 变 量 的 读 ， 总 是 能 看 到 【〈 任 意 线程 ) 对 
这 个 volatile 变 量 最 后 的 写 入 。 


锁 的 语义 决定 了 临界 区 代码 的 执行 具有 原子 性 。 这 意味 着 ， 即 使 是 
64 位 的 long 型 和 double 型 变量 ， 只 要 它 是 volatile 变 量 ， 对 该 变量 的 读 / 写 
就 具有 原子 性 。 如 果 是 多 个 volatile 操 作 或 类 似 于 volatile++ 这 种 复合 操 
作 ， 这 些 操作 整体 上 不 具有 原子 性 。 

















简 而 言 之 ，volatile 变 量 上 自身 具有 下 列 特性 。 


. 可 见 性 。 对 一 个 volatile 变 量 的 读 ， 总 是 能 看 到 【任意 线程 ) 对 这 


个 volatile 变 量 最 后 的 写 入 。 


. 原子 性 : 对 任意 单个 volatile 变 量 的 读 / 写 具有 原子 性 ， 但 类 似 于 
volatile++ 这 种 复合 操作 不 具有 原子 性 。 


3.4.2 ”volatile 写 - 读 建 立 的 happens-before 关 系 





上 面 讲 的 是 volatile 变 量 自身 的 特性 ， 对 程序 员 来 说 ，volatile 对 线程 
的 内 存 可 见 性 的 影响 比 volatile 自 身 的 特性 更 为 重要 ， 也 更 需要 我 们 去 关 
注 。 


从 JSR-133 开 始 ( 即 从 JDK5 开 始 ) ，volatile 变 量 的 写 - 读 可 以 实现 线 
程 之 间 的 通信 。 


从 内 存 语义 的 角度 来 说 ，volatile 的 写 - 读 与 锁 的 释放 -获取 有 相同 的 
内 存 效果 : volatile 写 和 锁 的 释放 有 相同 的 内 存 语义 ; volatile 读 与 锁 的 获 
取 有 相同 的 内 存 语义 。 


请 看 下 面 使 用 volatile 变 量 的 示例 代码 。 





class VolatileExample { 
int a= 0; 
volatile boolean flag = false; 
public void writer() { 
a= 1; // 1 
flag = true; // 2 


public void reader() { 
if (flag) { // 3 
int i = a; // 4 





假设 线程 A 执行 writer() 方 法 之 后 ， 线 程 B 执 行 reader0 方 法 。 根 据 


happens-before 规 则 ， 这 个 过 程 建 立 的 happens-before 关 系 可 以 分 为 3 类 : 





1) 根据 程序 次 序 规则 ，1 happens-before 2;3 happens-before 4。 
2) 根据 volatile 规 则 ，2 happens-before 3。 
3) 根据 happens-before 的 传递 性 规则 ，1 happens-before 4。 


上 述 happens-before 关 系 的 图 形 化 表现 形式 如 下 。 


线程 A 线程 B 


: 线程 A 修改 共享 


: 线程 A 写 volatile 







梅 色 租 头 


3: 线程 B 读 同一 个 


volatile” 











S 有 
里 





4: 线程 B 读 共享 
程序 顺序 规则 和 变量 
volatile 规 则 组 合 后 提 
供 的 happens before 
保证 : 1happens 
before 4 


图 3-16 ”happens-befote 关 系 


在 上 图 中 ， 每 一 个 第 头 链 接 的 两 个 节点 ， 代 表 了 一 个 happens-before 
关系 。 黑 色 箭 头 表 示 程 序 顺 序 规 则 ;橙色 箭头 表示 volatile 规 则 ; 蓝 色 箭 
头 表示 组 合 这 些 规则 后 提供 的 happens-before 保 证 。 


这 里 A 线 程 写 一 个 volatile 变 量 后 ，B 线 程 读 同一 个 volatile 变 量 。A 线 
程 在 写 volatile 变 量 之 前 所 有 可 见 的 共享 变量 ， 在 B 线 程 读 同一 个 volatile 





变量 后 ， 将 立即 变 得 对 B 线 程 可 见 。 


OO 注意 ”本文 统一 用 粗 实 线 标识 组 合 后 产生 的 happens-before 关 
系 。 


3.4.3 volatile 写 - 读 的 内 存 语义 


volatile 写 的 内 存 语 义 如 下 。 


当 写 一 个 volatile 变 量 时 ，JMM 会 把 该 线程 对 应 的 本 地 内 存 中 的 共享 


变量 值 刷 新 到 主 内 存 。 


以 上 面 示例 程序 VolatileExample 为 例 ， 假 设 线 程 A 首 先 执行 writer() 
方法 ， 随 后 线程 B 执 行 reader() 方 法 ， 初 始 时 两 个 线程 的 本 地 内 存 中 的 
flag 和 a 都 是 初始 状态 。 图 3-17 是 线程 A 执行 volatile 写 后 ， 共 享 变 量 的 状 


i 
态 示意 图 。 








线程 A 线程 B 






































本 地 内 存 A 本 地 内 存 B 
flag = true flag = false 
a=|] a=0 

写 
主 内 存 


flag = true 


a=] 








图 3-17 共享 变量 的 状态 示意 图 


如 图 3-17 所 示 ， 线 程 A 在 写 flag 变 量 后 ， 本 地 内 存 A 中 被 线程 A 更 新 
过 的 两 个 共 至 变量 的 值 被 刷新 到 主 内 存 中 。 此 时 ， 本 地 内 存 A 和 主 内 存 
中 的 共享 变量 的 值 是 一 致 的 。 





volatile 读 的 内 存 语义 如 下 。 


当 读 一 个 volatile 变 量 时 ，JMM 会 把 该 线程 对 应 的 本 地 内 存 置 为 无 


效 。 线 程 接 下 来 将 从 主 内 存 中 读 取 共 享 变量 。 








图 3-18 为 线程 B 读 同一 个 volatile 变 量 后 ， 共 享 变 量 的 状态 示意 网 。 


如 图 所 示 ， 在 读 flag 变 量 后 ， 本 地 内 存 B 包 含 的 值 己 经 被 置 为 无 
效 。 此 时 ， 线 程 B 必 须 从 主 内 存 中 读 取 共识 变量。 线程 B 的 读 取 操作 将 
导致 本 地 内 存 B 与 主 内 存 中 的 共 孚 变量 的 值 变 成 一 致 。 





如 果 我 们 把 volatile 写 和 volatile 读 两 个 步 又 综合 起 来 看 的 话 ， 在 读 线 
程 B 读 一 个 volatile 变 量 后 ， 写 线程 A 在 写 这 个 volatile 变 量 之 前 所 有 可 见 
的 共享 变量 的 值 都 将 立即 变 得 对 读 线 程 B 可 见 。 











下 面 对 volatile 写 和 volatile 读 的 内 存 语义 做 个 总 结 。 


线程 A 写 一 个 volatile 变 量 ， 实 质 上 是 线程 A 向 接 下 来 将 要 读 这 个 
volatile 变 量 的 某 个 线程 发 出 了 (其 对 共享 变量 所 做 修改 的 ) 消息 。 


. 线程 B 读 一 个 volatile 变 量 ， 实 质 上 是 线程 B 接 收 了 之 前 某 个 线程 发 


出 的 〈 在 写 这 个 volatile 变 量 之 前 对 共享 变量 所 做 修改 的 ) 消息 。 


.线程 A 写 一 个 volatile 变 量 ， 随 后 线程 B 读 这 个 volatile 变 量 ， 这 个 过 


程 实质 上 是 线程 A 通 过 主 内 存 向 线程 B 发 送 消息 。 


S 一 一 一 一 一 一 二 一 一 一 一 一 二 一 一 一 一 一 


作息、 区 
> 7 线 枉 B 
“ANB 发 送 消 入 。_ 
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图 3-18 共享 变量 的 状态 示意 图 


3.4.4 ” volatile 内 存 语义 的 实现 


下 面 来 看 看 JMM 如 何 实现 volatile 写 / 读 的 内 存 语义 


前 文 提 到 过 重 排序 分 为 编译 器 重 排序 和 处 理 器 重 排序 。 为 了 实现 
volatile 内 存 语 义 ，JMM 会 分 别 限制 这 两 种 类 型 的 重 排 序 类 型 。 表 3-5 是 
JMM 针 对 编译 器 制定 的 volatile 重 排序 规则 表 。 


表 3-5 volatile 重 排序 规则 表 


是 否 能 重 排序 第 二 
一个 扣 作 ET 


普通 读 / 


举例 来 说 ， 第 三 行 最 后 一 个 单元 格 的 意思 是 ， 在 程序 中 ， 当 第 一 个 
操作 为 普通 变量 的 读 或 写 时 ， 如 果 第 二 个 操作 为 volatile 写 ， 则 编译 器 不 
能 重 排序 这 两 个 操作 。 





从 表 3-5 我 们 可 以 看 出 。 


. 当 第 二 个 操作 是 volatile 写 时 ， 不 管 第 一 个 操作 是 什么 ， 都 不 能 重 
排序 。 这 个 规则 确保 volatile 写 之 前 的 操作 不 会 被 编译 器 重 排序 到 volatile 


写 之 后 。 


. 当 第 一 个 操作 是 volatile 读 时 ， 不 管 第 二 个 操作 是 什么 ， 都 不 能 
排序 。 这 个 规则 确保 volatile 读 之 后 的 操作 不 会 被 编译 器 重 排序 到 volatile 


读 之 前 。 


. 当 第 一 个 操作 是 volatile 写 ， 第 二 个 操作 是 volatile 读 时 ， 不 能 重 排 


为 了 实现 volatile 的 内 存 语义 ， 编 译 喜 在 生成 字 节 码 时 ， 会 在 指令 序 
列 中 插入 内 存 屏 障 来 禁止 特定 类 型 的 处 理 占 重 排序 。 对 于 编译 絮 来 说 ， 
发 现 一 个 最 优 布置 来 最 小 化 插入 屏障 的 总 数 儿 乎 不 可 能 。 为 此 ，JMM 采 
取保 守 策 略 。 下 面 是 基于 保守 策略 的 JMM 内 存 屏 障 插 入 策略 。 











` 在 每 个 volatile 写 操作 的 前 面 插入 一 个 StoreStore 屏 障 。 
. 在 每 个 volatile 写 操作 的 后 面 插入 一 个 StoreLoad 屏 障 。 
. 在 每 个 volatile 读 操作 的 后 面 插入 一 个 LoadLoad 屏 障 。 
. 在 每 个 volatile 读 操作 的 后 面 插入 一 个 LoadStote 屏 障 。 


上 述 内 存 屏障 插入 货 略 非常 保守 ， 但 它 可 以 保证 在 任意 处 理 器 平 
意 的 程序 中 都 能 得 到 正确 的 volatile 内 存 语义 。 


下 
(个 


下 面 是 保守 策略 下 ，volatile 写 插入 内 存 屏障 后 生成 的 指令 序列 示意 
图 ， 如 图 3-19 所 示 。 























普通 读 
禁止 上 面 的 普通 写 
指令 执 普通 写 和 下 面 
行 顺序 的 volatile 写 重 0 
排序 StoreStore 屏 障 
S 防止 上 面 的 
”| volatile 写 与 下 面 
volatile 写 可 能 有 的 volatile 





谈 / 写 重 排序 








StoreLoad 屏 障 





图 3-19 ”指令 序列 示意 图 


图 3-19 中 的 StoreStore 屏 障 可 以 保证 在 volatile 写 之 前 ， 其 前 面 的 所 有 
普通 写 操作 已 经 对 任意 处 理 嚣 可见 了 。 这 是 因为 StoreStore 屏 障 将 保障 
上 面 所 有 的 普通 写 在 volatile 写 之 前 刷新 到 主 内 存 。 


这 里 比较 有 意思 的 是 ，volatile 写 后 面 的 StoreLoad 屏 障 。 此 屏障 的 作 
用 是 避免 volatile 写 与 后 面 可 能 有 的 volatile 读 / 写 操作 重 排序 。 因 为 编译 
器 常常 无 法 准确 判断 在 一 个 volatile 写 的 后 面 是 否 需 要 插入 一 个 StoreLoad 
屏障 《比如 ， 一 个 volatile 写 之 后 方法 立即 return) 。 为 了 保证 能 正确 实 
现 volatile 的 内 存 语义 ，JMM 在 采取 了 保守 策略 : 在 每 个 volatile 写 的 后 
面 ， 或 者 在 每 个 volatile 读 的 前 面 插入 一 个 StoreLoad 屏 障 。 从 整体 执行 效 
率 的 角度 考虑 ，JMM 最 终 选 择 了 在 每 个 volatile 写 的 后 面 插入 一 个 





StoreLoad 屏 障 。 因 为 volatile 写 - 读 内 存 语义 的 常见 使 用 模式 是 : 一 个 写 
线程 号 volatile 变 量 ， 多 个 读 线程 读 同 一 个 volatile 变 量 。 当 读 线 程 的 数量 
大 大 超过 写 线程 时 ， 选 择 在 volatile 写 之 后 插入 StoreLoad 屏 障 将 带 来 可 观 
的 执行 效率 的 提升 。 从 这 里 可 以 看 到 JMM 在 实现 上 的 一 个 特点 : 首先 确 
保 正 确 性 ， 然 后 再 去 追求 执行 效率 。 





下 面 是 在 保守 策略 下 ，volatile 读 插入 内 存 屏 障 后 生成 的 指令 序列 示 
意图 ， 如 图 3-20 所 示 。 


volatile 读 





禁止 下 面 所 有 二 
的 普通 读 操 作 和 | LoadLoad 屏 障 
指令 执 | ”上 面 的 volatile 
行 顺序 读 重 排序 








LoadStore 屏 障 禁止 下 面 所 有 
的 普通 写 操作 和 
上 面 的 volatile 读 
普通 读 重 排序 




















图 3-20 ”指令 序列 示意 图 


图 3-20 中 的 LoadLoad 屏 障 用 来 禁止 处 理 器 把 上 耐 的 volatile 读 与 下 面 
的 普通 读 重 排序 。LoadStore 屏 障 用 来 禁止 处 理 堪 把 上 面 的 volatile 读 与 下 
面 的 普通 写 重 排序 。 





上 述 volatile 写 和 volatile 读 的 内 存 屏 障 插入 策略 非常 保守 。 在 实际 执 
行 时 ， 只 要 不 改变 volatile 写 - 读 的 内 存 语义 ， 编 译 器 可 以 根据 具体 情况 
省 略 不 必要 的 屏障 。 下 面 通过 有 具体 的 示例 代码 进行 说 明 。 











class VolatileBarrierExample { 
int a; 
volatile int vi = 
volatile int v2 = 
void en ie { 

















int. Le V1 // 第 一 个 volatile 读 
int j = v2; // 第 二 个 volatile 读 
a=i+j; // 普通 写 

vV1=i+1; // 第 一 个 volatile 写 
v2=j* 2; // 第 二 个 volatile 写 








// 其 他 方法 





针对 readAndWrite() 方 法 ， 编 译 占 在 生成 字 节 人 码 时 可 以 做 如 下 的 优 
化 。 


指令 执 
行 顺 序 














禁止 上 面 的 
volatile 读 和 下 
面 的 volatile 读 
重 排序 


禁止 下 面 的 
普通 写 和 上 面 
的 volatile 读 重 


排序 


省 略 StoreLoad 
屏障 ， 仅 仅 搬 入 
StoreStore 屏 障 即 
可 。 因 为 下 面 跟 
着 一 个 volatile 写 


防止 上 面 的 
volatile 写 与 后 面 
可 能 有 的 volatile 
读 / 写 重 排序 








第 一 个 volatile 读 








LoadLoad 屏 障 








太 所 


第 二 个 volatile 读 








LoadStore 屏 障 


普通 写 


StoreStore 屏 障 | 











第 一 个 volatile 写 ] 








| “StoreStore 屏 障 











第 二 个 volatile 写 





StoreLoad 屏 障 





这 里 省 略 了 Load- 
Store 屏 障 ， 因 为 下 
面 的 普通 写 根 本 不 
可 能 越过 上 面 的 


volatile 读 


这 里 省 略 了 
LoadLoad 屏 障 ， 
因为 下 面 根本 没 
有 普通 读 操 作 


禁止 上 面 的 普通 
写 和 下 面 的 volatile 
写 重 排序 


禁止 上 面 的 volatile 
写 与 下 面 的 volatile 写 
重 排序 


图 3-21 指令 序列 示意 图 


注意 ， 最 后 的 StoreLoad 屏 障 不 能 省 略 。 因 为 第 二 个 volatile 写 之 后 ， 
方法 立即 return。 此 时 编译 器 可 能 无 法 准确 断定 后 面 是 否 
或 号 ， 为 了 安全 起 见 ， 编 译 器 通 节 会 





会 有 volatile 读 
车 这 里 插入 一 个 StoreLoad 屏 障 。 


上 面 的 优化 针对 任意 处 理 器 平台 ， 由 于 不 同 的 处 理 占 有 不 同 “ 松 紧 
度 ” 的 处 理 器 内 存 模型 ， 内 存 屏障 的 插入 还 可 以 根据 具体 的 处 理 需 内 存 


模型 继续 优化 。 以 X86 处 理 器 为 例 ， 图 3-21 中 除 最 后 的 StoreLoad 屏 障 
外 ， 其 他 的 屏障 都 会 被 省 略 。 


前 面 保守 策略 下 的 volatile 读 和 写 ， 在 X86 处 理 器 平台 可 以 优化 成 如 
图 3-22 所 示 。 


前 文 提 到 过 ，X86 处 理 嚣 仅 会 对 写 - 读 操 作 做 重 排序 。X86 不 会 对 读 - 
读 、 读 - 写 和 写 - 写 操作 做 重 排序 ， 因 此 在 X86 处 理 器 中 会 省 略 掉 这 3 种 操 
作 类 型 对 应 的 内 存 屏 障 。 在 X86 中 ，JMM 仅 需 在 volatile 写 后 面 插入 一 个 
StoreLoad 屏 障 即 可 正确 实现 volatile 写 - 读 的 内 存 语义 。 这 意味 着 在 X86 
处 理 器 中 ，volatile 写 的 开销 比 volatile 读 的 开销 会 大 很 多 (因为 执行 
StoreLoad 屏 障 开销 会 比较 大 )〉。 












































Volatile 与 volatile 读 
普通 读 | volatile 读 
活 通 写 普通 读 
指令 执 
行 顺序 
1 1 其 
本 volatile 写 普通 写 
面 可 能 有 的 
volatile 读 / 写 重 | y 
非 序 StoreLoad 屏 障 
排序 | 而 
vy - 


图 3-22 ”指令 序列 示意 图 


3.4.5 JSR-133 为 什么 要 增强 volatile 的 内 存 语 义 


在 JSR-133 之 前 的 旧 Java 内 存 模型 中 ， 虽 然 不 允许 volatile 变 量 之 间 
重 排序 ， 但 旧 的 Java 内 存 模型 允许 volatile 变 量 与 普通 变量 重 排序 。 在 旧 
的 内 存 模型 中 ，VolatileExample 示 例 程 序 可 能 被 重 排序 成 下 列 时 序 来 执 
行 ， 如 图 3-23 所 示 。 


线程 A 线程 B 








时 间 





1: 线程 A 修改 共享 





图 3-23 ”线程 执行 时 序 图 


在 旧 的 内 存 模 型 中 ， 当 1 和 2 之 间 没 有 数据 依赖 关系 时 ，1 和 2 之 间 就 
可 能 被 重 排 序 (3 和 4 类 似 ) 。 其 结果 就 是 : 读 线 程 B 执 行 4 时 ， 不 一 定 能 
看 到 写 线程 A 在 执行 1 时 对 共享 变量 的 修改 。 








因此 ， 在 旧 的 内 存 模 型 中 ，volatile 的 写 - 读 没有 锁 的 释放 - 获 所 具有 
的 内 存 语义 。 为 了 提供 一 种 比 锁 更 轻 量 级 的 线程 之 间 通 信 的 机制 ，JSR- 
133 专 家 组 决定 增强 volatile 的 内 存 语义 :， 严格 限制 编译 费 和 处 理 絮 对 
volatile 变 量 与 普通 变量 的 重 排序 ， 确 保 volatile 的 写 - 读 和 锁 的 释放 -获取 
有 具 有 相同 的 内 存 语义 。 从 编译 器 重 排 序 规则 和 处 理 器 内 存 屏障 插入 策略 
来 看 ， 只 要 volatile 变 量 与 普通 变量 之 则 的 重 排序 可 能 会 破坏 volatile 的 内 
存 语义 ， 这 种 重 排 序 就 会 被 编译 器 重 排序 规则 和 处 理 器 内 存 屏障 插入 策 
略 禁止 。 








由 于 volatile 仅 仅 保 证 对 单个 volatile 变 量 的 读 / 写 具有 原子 性 ， 而 锁 
的 互 斥 执行 的 特性 可 以 确保 对 整个 临界 区 代码 的 执行 具有 原子 性 。 在 功 
能 上 ， 锁 比 volatile 更 强大 ; 在 可 伸缩 性 和 执行 性 能 上 ，volatile 更 有 优 
势 。 如 果 读 者 想 在 程序 中 用 volatile 代 替 锁 ， 请 一 定 谨慎 ， 有 具体 详情 请 参 
阅 Brian Goetz 的 文章 《Java 理 论 与 实践 : 正确 使 用 Volatile 变 量 》 。 








3.5 锁 的 内 存 语义 


众所周知 ， 锁 可 以 让 临界 区 互 太 执行。 这 里 将 介绍 锁 的 另 一 个 同样 
重要 ， 但 第 第 被 忽视 的 功能 : 锁 的 内 存 语义 。 





3.5.1 锁 的 释放 -获取 建立 的 happens-before 关 系 





锁 是 Java 并 发 编程 中 最 重要 的 同步 机 制 。 锁 除了 让 临界 区 互 斥 执行 
外 ， 还 可 以 让 释放 锁 的 线程 加 获取 同一 个 锁 的 线程 及 送 消 居 。 


下 面 是 锁 释 放 - 获 取 的 示例 代码 。 





class MonitorExample { 


int a = 0; 

public synchronized void writer() { //1 
at+; // 2 

} // 3 

public synchronized void reader() { // 4 
int i = a; YA 

} // 6 





假设 线程 A 执行 writer0) 方 法 ， 随 后 线程 B 执 行 reader0) 方 法 。 根 据 
happens-before 规 则 ， 这 个 过 程 包含 的 happens-before 关 系 可 以 分 为 3 类 。 





1) 根据 程序 次 序 规 则 ，1 happens-before 2,2 happens-before 3;4 


happens-before 5,5 happens-before 6。 
2) 根据 监视 器 锁 规则 ，3 happens-before 4。 
3) 根据 happens-before 的 传递 性 ，2 happens-before 5。 


上 述 happens-before 关 系 的 图 形 化 表现 形式 如 图 3-24 所 示 。 


线程 A 线程 B 








1: 线程 A 获 取 锁 











2: 线程 A 执行 临界 
区 中 的 代码 












3: 线程 A 释放 锁 


橙色 箭头 





4: 线程 B 获 取 同 一 
个 锁 


监 色 箭 头 






5: 线程 B 执 行 临界 


程序 顺序 规则 和 监视 区 中 的 代码 


器 锁 规 则 组 合 后 ， 提 供 
的 happens-before 保 证 
2 happens-before > 6: 线程 B 释 放 锁 


图 3-24 happens-before 关 系 图 


在 图 3-24 中 ， 每 一 个 第 头 链接 的 两 个 市 点 ， 代 表 了 一 个 happens- 
before 关 系 。 黑 色 箭 头 表示 程序 顺序 规则 ;橙色 箭头 表示 监视 器 锁 规 
则 ;， 蓝 色 箭头 表示 组 合 这 些 规 则 后 提供 的 happens-before 保 证 。 





图 3-24 表 示 在 线程 A 释 放 了 锁 之 后 ， 随 后 线程 B 获 取 同 一 个 锁 。 在 





上 图 中 ，2 happens-before 5。 因 此 ， 线 程 A 在 释放 锁 之 前 所 有 可 见 的 共 
享 变量 ， 在 线程 B 获 取 同 一 个 锁 之 后 ， 将 立刻 变 得 对 B 线 程 可 见 。 





3.5.2” 锁 的 释放 和 获取 的 内 存 语义 
当 线 程 释放 锁 时 ，JMM 会 把 该 线程 对 应 的 本 地 内 存 中 的 共享 变量 刷 


新 到 主 内 存 中 。 以 上 面 的 MonitorExample 程 序 为 例 ，A 线 程 释放 锁 后 ， 
共享 数据 的 状态 示意 图 如 图 3-25 所 示 。 


本 地 内 存 A 本 地 内 存 B 








a=1 a=0 





























图 3-25 ”共享 数据 的 状态 示意 图 


当 线 程 获 取 锁 时 ，JMM 会 把 该 线程 对 应 的 本 地 内 存 置 为 无 效 。 从 而 
使 得 被 监视 器 保护 的 临界 区 代码 必须 从 主 内 存 中 读 取 共 享 变量 。 图 3-26 


古 锁 获取 的 状态 示意 图 。 
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图 3-26 人 锁 获 取 的 状态 示意 图 


对 比 锁 释放 -获取 的 内 存 语义 与 volatile 写 - 读 的 内 存 语 义 可 以 看 出 : 
锁 释 放 与 volatile 写 有 相同 的 内 存 语义 ; 锁 获 取 与 volatile 谈 有 相同 的 内 存 
语义 。 


下 面 对 锁 释放 和 锁 获 取 的 内 存 语 义 做 个 总 结 。 


线程 A 释 放 一 个 锁 ， 实 质 上 是 线程 A 向 接 下 来 将 要 获取 这 个 锁 的 
某 个 线程 发 出 了 (线程 A 对 共享 变量 所 做 修改 的 ) 消息 。 


线程 B 获 取 一 个 锁 ， 实 质 上 是 线程 B 接 收 了 之 前 茶 个 线程 发 出 的 
〈 在 释放 这 个 锁 之 前 对 共享 变量 所 做 修改 的 ) 消息 。 
` 线程 人 释放 锁 ， 随 后 线程 B 获 取 这 个 锁 ， 这 个 过 程 实质 上 是 线程 人 


通过 主 内 存 向 线程 B 发 送 消息 。 


3.5.3” 锁 内 存 语义 的 实现 


本 文 将 借助 ReentrantLock 的 源 代 码 ， 来 分 析 锁 内 存 语义 的 具体 实现 
机 制 |。 


请 看 下 面 的 示例 代码 。 





Class ReentrantLockExample { 
int a = 0; 
ReentrantLock lock = new ReentrantLock(); 
public void writer() { 
lock.1lock(); // 获取 锁 
try { 
a++， 
}Ff inally { 
lock.unlock(); // 释放 锁 
} 


public void reader () { 
lock.1lock(); // 获取 锁 
try { 


}f inally { 
lock.unlock();  // 释放 锁 





在 ReentrantLock 中 ， 调 用 lock0) 方 法 获取 锁 ; 调用 unlockO0 方 法 释放 
镜 O 


ReentrantLock 的 实现 依赖 于 Java 同 步 器 框架 
AbstractQueuedSynchronizer 〈 本 文 简称 之 为 AQS) 。AQS 使 用 一 个 整 型 
的 volatile 变 量 〈 命 名 为 state) 来 维护 同步 状态 ， 马 上 我 们 会 看 到 ， 这 个 





volatile 变 量 是 ReentrantLock 内 存 语 义 实 现 的 关键 。 


图 3-27 是 ReentrantLock 的 类 图 〈 仅 画 出 与 本 文 相关 的 部 分 ) 。 





AbstractQueuedSynchronizer 
- private volatile int state; ; int 


+ public final void acquire(lint arg ; int) ; void 
+ public final boolean releasefint arg :inb :void 


+ protected final boolean tryReleasetint releases : int) : void 
+final boolean nonfairTryAcoquire(int acduires int :void 


ES 了 


+fnalvoid lockO :Yoid + final ¥oid lockO : void 
+ protected final hboolean tyAcquiretint acquires ; int) ; void + protected final boolean tryAcquirelint acquires ; int) :void 


ReentrantLock 


- private fnal Sync Sync int 


+ public void IockO : void 
+ public void unlockd : void 


图 3-27 ReentrantLock 的 类 图 


0 





ReentrantLock 分 为 公平 锁 和 非 公平 锁 ， 我 们 首先 分 析 公 平 锁 。 


使 用 公平 锁 时 ， 加 锁 方 法 lock0 调 用 轨迹 如 下 。 


1) ReentrantLock:lock()。 


2) FairSync:lock()。 


3) AbstractQueuedSynchronizer:acquire(int arg)。 


4) ReentrantLock:tryAcquire(int acquires) 。 


在 第 4 步 真 正 开 始 加 锁 ， 下 面 是 该 方法 的 源 代 码 。 





protected final boolean tryAcquire(int acquires) { 

final Thread current = Thread.currentThread(); 

int c = getstate(); // 获取 锁 的 开始 ， 首 先 读 volatile 变 量 state 

if (c == 0) { 

If (isFirst(current) && 
compareAndSetState(0, acquires)) { 

setExclusiveOwnerThread(current); 
return true; 





























} 


else if (current == getExclusiveOwnerThread()) { 
int nextc = c + acquires,; 
if (nextc < 0) 
throw new Error("Maximum lock count exceeded"); 
SetState(nextc ) ， 
return true; 


return false; 





从 上 上面 源 代码 中 我 们 可 以 看 出 ， 加 锁 方 法 首先 恋 volatile 变 量 state。 
在 使 用 公平 锁 时 ， 解 锁 方 法 unlockO 调 用 轨迹 如 下 。 
1) ReentrantLock:unlock()。 


2) AbstractQueuedSynchronizer:release(int arg)。 


3) Sync:tryRelease(int releases)。 


在 第 3 步 真正 开始 释放 锁 ， 下 面 是 该 方法 的 源 代码 。 





protected final boolean tryRelease(int releases) { 

int c = getState() - releases,; 

if (Thread,currentThread() != getExclusiveOwnerThread()) 
throw new IllegalMonitorStateException(); 

boolean free = false; 

if (c == 0) { 
free = true,; 
setExclusiveOwnerThread(null); 


} 
setstate(c); // 释放 锁 的 最 后 ， 写 volatile 变 量 state 
return free,; 








从 上 面 的 源 代码 可 以 看 出 ， 在 释放 锁 的 最 后 写 volatile 变 量 state。 


公平 锁 在 释放 锁 的 最 后 写 volatile 变 量 state， 在 获取 锁 时 首先 恋 这 个 
volatile 变 量 。 根 据 volatile 的 happens-before 规 则 ， 释 放 锁 的 线程 在 写 
volatile 变 量 之 前 可 见 的 共享 变量 ， 在 获取 锁 的 线程 读 取 同一 个 volatile 变 
量 后 将 立即 变 得 对 获取 锁 的 线程 可 见 。 





现在 我 们 来 分 析 非 公平 锁 的 内 存 语 义 的 实现 。 非 公平 锁 的 释放 和 公 
平 锁 完全 一 样 ， 所 以 这 里 仅仅 分 析 非 公平 锁 的 获取 。 使 用 非 公平 锁 时 ， 
加 锁 方 法 lockO 调 用 轨迹 如 下 。 


1) ReentrantLock:lock()。 


2) NonfairSync:lock()。 


3) AbstractQueuedSynchronizer:compareAndSetState(int expect,int 


update)。 


在 第 3 步 真正 开始 加 锁 ， 下 面 是 该 方法 的 源 代 码 。 





protected final boolean compareAndSetState(int expect, int update) { 
return unsafe,.compareAndSwapInt(this，stateoffset，expect，update ) 
} 





该 方法 以 原子 操作 的 方式 更 新 state 变 量 ， 本 文 把 Java 的 
compareAndSet() 方 法 调用 简称 为 CAS。JDK 文 档 对 该 方法 的 说 明 如 下 : 
如 果 当 前 状态 值 等 于 预期 值 ， 则 以 原子 方式 将 同步 状态 设置 为 给 定 的 更 
新 值 。 此 操作 具有 volatile 读 和 写 的 内 存 语 义 。 





这 里 我 们 分 别 从 编译 器 和 处 理 器 的 角度 来 分 析 ，CAS 如 何 同时 具有 
volatile 读 和 volatile 写 的 内 存 语义 。 


前 文 我 们 提 到 过 ， 编 译 器 不 会 对 volatile 读 与 volatile 读 后 面 的 任意 内 
存 操作 重 排序 ， 编 译 器 不 会 对 volatile 写 与 volatile 写 前 面 的 任意 内 存 操作 
重 排 序 。 组 合 这 两 个 条 件 ， 意 味 着 为 了 同时 实现 volatile 读 和 volatile 写 的 
内 存 语义 ， 编 译 器 不 能 对 CAS 与 CAS 前 面 和 后 面 的 任意 内 存 操作 重 排 
|i 





下 面 我 们 来 分 析 在 常见 的 intel X86 处 理 器 中 ，CAS 是 如 何 同时 具有 
volatile 读 和 volatile 写 的 内 存 语义 的 。 


下 面 是 sun.misc.Unsafe 类 的 compareAndSwapIntO 方 法 的 源 代 码 。 





public final native boolean compareAndSwapInt(Object o, long offset, 








可 以 看 到 ， 这 是 一 个 本 地 方法 调用 。 这 个 本 地 方法 在 openjdk 中 依 
次 调用 的 c++ 代码 为 : unsafe.cpp，atomic.cpp 和 
atomic_windows_x86.inline.hpp。 这 个 本 地 方法 的 最 终 实现 在 openjdk 的 
如 下 位 置 : openjdk-7-fcs-src-b147- 
27_jun_2011\openjdk\hotspot\sro\os_cpu\windows_x86\vm\atomic windows. 
应 于 Windows 操 作 系统 ，X86 处 理 器 ) 。 下 面 是 对 应 于 intel X86 处 理 器 
的 源 代码 的 片段 。 





inline jint Atomic: :cmpxchg (jint exchange_value, volatile jint* dest 

jint compare_value) { 

// alternative for InterlockedCompareExchange 

int mp = os::is_ MP(); 

_asmf{ 
mov edx, dest 
mov ecx, exchange_value 
mov eax, compare_value 
LOCK_IF_MP(mp) 
cmpxchg dword ptr [edx], ecx 











如 上 面 源 代码 所 示 ， 程 序 会 根据 当前 处 理 器 的 类 型 来 决定 是 否 关 
cmpxchg 指 令 添加 lock 前 级 。 如 果 程 序 是 在 多 处 理 器 上 运行 ， 就 为 
cmpxchg 指 令 加 上 lock 前 级 (Lock Cmpxchg) 。 反 之 ， 如 果 程 序 是 在 单 
处 理 器 上 运行 ， 就 省 略 lock 前 缀 《〈 单 处 理 器 自身 会 维护 单 处 理 器 内 的 顺 


序 一 致 性 ， 不 需要 lock 前 绥 提 供 的 内 存 屏障 效果 ) 。 
intel 的 手册 对 lock 前 级 的 说 明 如 下 。 


1) 确保 对 内 存 的 读 - 改 - 写 操作 原子 执行 。 在 Pentium 及 Pentium 之 前 
的 处 理 器 中 ， 带 有 lock 前 缀 的 指令 在 执行 期 间 会 锁 住 总 线 ， 使 得 其 他 处 
理 器 暂时 无 法 通过 总 线 访问 内 存 。 很 显然 ， 这 会 带 来 昂贵 的 开销 。 从 
Pentium 4、Intel Xeon 及 P6 处 理 器 开始 ，Intel 使 用 绥 存 锁定 〈Cache 
Locking) 来 保证 指令 执行 的 原子 性 。 绥 存 锁 定 将 大 大 降低 lock 前 级 指令 
的 执行 开销 。 





2) 禁止 该 指令 ， 与 之 前 和 之 后 的 读 和 写 指令 重 排序 。 


3) 把 写 缓冲 区 中 的 所 有 数据 刷新 到 和 内存 中 。 





上 面 的 第 2 点 和 第 3 点 所 具有 的 内 存 屏障 效果 ， 足 以 同时 实现 volatile 
访 和 volatile 写 的 内 存 语义 。 


经 过 上 面 的 分 析 ， 现 在 我 们 终于 能 明白 为 什么 JDK 文 档 说 CAS 同 时 
具有 volatile 读 和 volatile 写 的 内 存 语 义 了 。 


现在 对 公平 锁 和 非 公平 锁 的 内 存 语义 做 个 总 结 。 


. 公平 锁 和 非 公平 锁 释 放 时 ， 最 后 都 要 写 一 个 volatile 变 量 state。 


. 公平 锁 获 取 时 ， 首 先 会 去 读 volatile 变 量 。 


. 非 公 平 锁 获取 时 ， 首 先 会 用 CAS 更 新 volatile 变 量 ， 这 个 操作 同时 


具有 volatile 读 和 volatile 写 的 内 存 语 义 。 


从 本 文 对 ReentrantLock 的 分 析 可 以 看 出 ， 锁 释放 -获取 的 内 存 语义 
的 实现 至 少 有 下 面 两 种 方式 。 


1) 利用 volatile 变 量 的 写 - 读 所 具有 的 内 存 语义 。 





2) 利用 CAS 所 附带 的 volatile 读 和 volatile 写 的 内 存 语义 。 


3.5.4 ”concurrent 包 的 实现 


由 于 Java 的 CAS 同 时 具有 volatile 读 和 volatile 写 的 内 存 语 义 ， 因 此 
Java 线 程 之 间 的 通信 现在 有 了 下 面 4 种 方式 。 


1) A 线 程 写 volatile 变 量 ， 随 后 B 线 程 读 这 个 volatile 变 量 。 
2) A 线 程 写 volatile 变 量 ， 随 后 B 线 程 用 CAS 更 新 这 个 volatile 变 量 。 


3) A 线程 用 CAS 更 新 一 个 volatile 变 量 ， 随 后 B 线 程 用 CAS 更 新 这 个 


volatile 变 量 。 


4) A 线 程 用 CAS 更 新 一 个 volatile 变 量 ， 随 后 B 线 程 读 这 个 volatile 变 


-四 
里 。 


Java 的 CAS 会 使 用 现代 处 理 器 上 提供 的 高 效 机 器 级 别 的 原子 指令 ， 
这 些 原子 指令 以 原子 方式 对 内 存 执行 读 - 改 - 写 操作 ， 这 是 在 多 处 理 器 中 
实现 同步 的 关键 (从 本 质 上 来 说 ， 能 够 支持 原子 性 读 - 改 - 写 指令 的 计算 
机 ， 证 顺序 计算 图 元 机 的 异步 等 价 机 器 ， 因 此 任何 现代 的 多 处 理 器 都 会 
去 文 持 茶 种 能 对 内 存 执行 原子 性 读 - 改 - 写 操 作 的 原子 指令 ) 。 同 时 ， 
volatile 变 量 的 读 / 写 和 CAS 可 以 实现 线程 之 间 的 通信 。 把 这 些 特性 整合 
在 一 起 ， 就 形成 了 整个 concurrent 包 得 以 实现 的 基石 。 如 采 我 们 仔细 分 
析 concurrent 包 的 源 代码 实现 ， 会 发 现 一 个 通用 化 的 实现 模式 。 











首先 ， 声 明 共 享 变 量 为 volatile。 

然后 ， 使 用 CAS 的 原子 条 件 更 新 来 实现 线程 之 间 的 同步 。 

同时 ， 配 合 以 volatile 的 读 / 写 和 CAS 所 具有 的 volatile 读 和 写 的 内 存 
语义 来 实现 线程 之 间 的 通信 。 


AQS， 非 阻塞 数据 结构 和 原子 变量 类 (java.util.concurrent.atomic 包 
中 的 类 ) ， 这 些 concurrent 包 中 的 基础 类 都 是 使 用 这 种 模式 来 实现 的 ， 
而 concurrent 包 中 的 高 层 类 又 是 依赖 于 这 些 基础 类 来 实现 的 。 从 整体 来 
看 ，concurrent 包 的 实现 示意 图 如 3-28 所 示 。 










































































Lock 同步 需 阻塞 队列 Executor 并 发 容 需 
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concurtent 包 的 实现 1 


图 3-28 


3.6_ final 域 的 内 存 语义 





与 前 面 介绍 的 锁 和 volatile 相 比 ， 对 final 域 的 读 和 写 更 像 是 普通 的 变 
量 访问 。 下 面 将 介绍 final 域 的 内 存 语 义 。 





3.6.1 ”final 域 的 重 排 序 规则 


对 于 final 域 ， 编 译 器 和 处 理 器 要 遵守 两 个 重 排 序 规则 。 


1) 在 构造 函数 内 对 一 个 final 域 的 写 入 ， 与 随后 把 这 个 被 构造 对 象 
的 引用 赋值 给 一 个 引用 变量 ， 这 两 个 操作 之 间 不 能 重 排序 。 


2) 初次 读 一 个 包含 final 域 的 对 象 的 引用 ， 与 随后 初次 读 这 个 final 
域 ， 这 两 个 操作 之 间 不 能 重 排序 。 


下 面 通过 一 些 示 例 性 的 代码 来 分 别 说 明 这 两 个 规则 。 





public class FinalExample { 
























































int 工 ; // 普通 变量 

final int j; // final 变 量 

static FinalExample obj; 

public FinalExample () { // 构造 函数 
es // 写 普通 域 
于 过 之， // 写 final 域 

} 

public static void writer () { // 写 线程 A 执行 
obj = new FinalExample (); 

} 

public static void reader () { // 读 线 程 B 执 行 
FinalExample object = obj; // 读 对 象 引 用 
int a = object.i; // 读 普 通 域 
int b = object.j; // 读 final 域 





这 里 假设 一 个 线程 A 执行 writer() 方 法 ， 随 后 另 一 个 线程 B 执 行 
reader() 方 法 。 下 面 我 们 通过 这 两 个 线程 的 交互 来 说 明 这 两 个 规则 。 


3.6.2” 写 final 域 的 重 排序 规则 

写 final 域 的 重 排序 规则 禁止 把 final 域 的 写 重 排序 到 构造 函数 之 外 。 
这 个 规则 的 实现 包含 下 面 2 个 方面 。 

1) JMM 禁 止 编译 器 把 final 域 的 写 重 排序 到 构造 函数 之 外 。 


2) 编译 器 会 在 final 域 的 写 之 后 ， 构 造 函 数 return 之 前 ， 插 入 一 个 
StoreStore 屏 障 。 这 个 屏障 禁止 处 理 器 把 final 域 的 写 重 排序 到 构造 函数 之 
外 。 


现在 让 我 们 分 析 writer() 方 法 。writer0 方 法 只 包含 一 行 代码 : 
finalExample=new FinalExample0。 这 行 代码 包含 两 个 步骤 ， 如 下 。 


1) 构造 一 个 FinalExample 类 型 的 对 象 。 


2) 把 这 个 对 象 的 引用 赋值 给 引用 变量 obj。 





假设 线程 B 读 对 象 引用 与 读 对 象 的 成 员 域 之 间 没 有 重 排序 〈 马 上 会 
说 明 为 什么 需要 这 个 假设 ) ， 图 3-29 是 一 种 可 能 的 执行 时 序 。 


在 图 3-29 中 ， 写 普通 域 的 操作 被 编译 器 重 排 序 到 了 构造 汕 数 之 外 ， 
读 线 程 B 错 误 地 读 取 了 普通 变量 i 初始 化 之 前 的 值 。 而 写 final 域 的 操作 ， 
被 写 final 域 的 重 排序 规则 “限定 ?在 了 构造 函数 之 内 ， 读 线程 B 正 确 地 读 





取 了 final 变 量 初始 化 之 后 的 值 。 


写 final 域 的 重 排序 规则 可 以 确保 : 在 对 象 引 用 为 任意 线程 可 见 之 
前 ， 对 象 的 final 域 己 经 被 正确 初始 化 过 了 ， 而 普通 域 不 具有 这 个 保障 。 
以 上 图 为 例 ， 在 读 线 程 B“ 看 到 ”对 象 引 用 obj 时 ， 很 可 能 obj 对 象 还 没有 构 
造 完 成 《对 普通 域 i 的 写 操作 被 重 排序 到 构造 函数 外 ， 此 时 初始 值 1 还 没 
有 写 入 普通 域 i) 。 





线程 A 线程 B 


构造 函数 开始 执行 








时 间 











图 3-29 ”线程 执行 时 序 图 


3.6.3” 读 final 域 的 重 排序 规则 


读 final 域 的 重 排 序 规则 是 ， 在 一 个 线程 中 ， 初 次 读 对 象 引 用 与 初次 
读 该 对 象 包含 的 final 域 ，JMM 禁 止 处 理 器 重 排 序 这 两 个 操作 (注意 ， 这 
个 规则 仅仅 针对 处 理 器 ) 。 编 译 器 会 在 读 final 域 操作 的 前 面 插入 一 个 
LoadLoad 屏 障 。 





初次 读 对 象 引用 与 初次 读 该 对 象 包含 的 final 域 ， 这 两 个 操作 之 间 存 
在 间接 依赖 关系 。 由 于 编译 需 遭 守 间 接 依赖 和 关系， 因此 编译 器 不 会 重 排 
序 这 两 个 操作 。 大 多 数 处 理 需 也 会 章 守 间 接 依赖 ， 也 不 会 重 排序 这 两 个 
操作 。 但 有 少数 处 理 需 允许 对 存在 间接 依赖 关系 的 操作 做 重 排序 《比如 
alpha 处 理 器 ) ， 这 个 规则 惑 是 专门 用 来 针对 这 种 处 理 器 的 。 





reader() 方 法 包含 3 个 操作 。 
` 初次 读 引 用 变量 obj。 
` 初次 读 引 用 变量 obj 指 向 对 象 的 普通 域 j。 


` 初次 读 引 用 变量 obj 指 向 对 象 的 final 域 i。 











现在 假设 写 线 程 A 没 有 发 生 任 何 重 排序 ， 同 时 程序 在 不 遵守 间接 依 
赖 的 处 理 器 上 执行 ， 图 3-30 所 示 和 是 一 种 可 能 的 执行 时 序 。 


线程 A 





构造 函 数 开 始 执行 




















写 final 域 : 
| = 沁 








时 间 





StoreStore 屏 障 


构造 函数 执行 结束 








把 构造 对 象 的 引用 


赋值 给 引用 变量 obj 











读 对 象 引 用 obj 











LoadLoad 屏 障 





读 对 象 的 final 域 | 





图 3-30 ”线程 执行 时 序 图 


在 图 3-30 中 ， 读 对 象 的 普通 域 的 操作 被 处 理 器 重 排序 到 读 对 象 引用 
之 前 。 访 普通 域 时 ， 该 域 还 没有 被 写 线程 A 写 入 ， 这 是 一 个 错误 的 读 取 
操作 。 而 读 final 域 的 重 排序 规则 会 把 读 对 象 final 域 的 操作 “限定 ?在 读 对 
象 引用 之 后 ， 此 时 该 final 域 已 经 被 A 线 程 初始 化 过 了 ， 这 是 一 个 正确 的 





读 取 操作 。 


读 fina] 域 的 重 排序 规则 可 以 确保 : 在 读 一 个 对 象 的 final 域 之 前 ， 一 
定 会 先 读 包含 这 个 final 域 的 对 象 的 引用 。 在 这 个 示例 程序 中 ， 如 果 该 引 
用 不 为 null， 那 么 引用 对 象 的 final 域 一 定 已 经 被 A 线程 初始 化 过 了 。 


3.6.4 ”final 域 为 引用 类 型 


上 面 我 们 看 到 的 final 域 是 基础 数据 类 型 ， 如 果 final 域 是 引用 类 型 ， 
将 会 有 什么 效果 ?请 看 下 列 示 例 代码 。 





public class FinalReferenceExample { 
final int[] intArray; // final 是 引用 类 型 























static FinalReferenceExample obj; 


public FinalReferenceExample () { // 构造 函数 
intArray = new int[1]; //1 
intArray[0] = 1; // 2 

} 

public static void writerone () { // 写 线程 A 执行 
obj = new FinalReferenceExample (); // 3 

} 

public static void writerTwo () { // 写 线程 B 执 行 
obj,intArray[0] = 2; // 4 

public static void reader () { // 读 线 程 C 执 行 
if (obj != nul1) { // 5 

int temp1 = obj.intArray[0]; // 6 

} 

} 


} 





本 例 final 域 为 一 个 引用 类 型 ， 它 引用 一 个 int 型 的 数组 对 象 。 对 于 引 
用 类 型 ， 写 final 域 的 重 排 序 规则 对 编译 占 和 处 理 器 增加 了 如 下 约束 : 在 
构造 函数 内 对 一 个 final 引 用 的 对 象 的 成 员 域 的 写 入 ， 与 随后 在 构造 函数 
外 把 这 个 被 构造 对 象 的 引用 赋值 给 一 个 引用 变量 ， 这 两 个 操作 之 间 不 能 
重 排 序 。 





对 上 面 的 示例 程序 ， 假 设 首 先 线程 A 执行 writerOne() 方 法 ， 执 行 完 
后 线程 B 执 行 writerTwo() 方 法 ， 执 行 完 后 线程 C 执 行 reader() 方 法 。 图 3- 


31 是 一 种 可 能 的 线程 执行 时 序 。 


在 图 3-31 中 ，1 是 对 final 域 的 写 入 ，2 是 对 这 个 final 域 引用 的 对 象 的 
成 员 域 的 写 入 ，3 是 把 被 构造 的 对 象 的 引用 赋值 给 某 个 引用 变量 。 这 里 
除了 前 面 提 到 的 1 不 能 和 3 重 排序 外 ，2 和 3 也 不 能 重 排序 。 





JMM 可 以 确保 读 线程 C 至 少 能 看 到 写 线程 A 在 构造 函数 中 对 final 引 
用 对 象 的 成 员 域 的 号 入 。 即 C 至 少 能 看 到 数组 下 标 0 的 值 为 1。 而 写 线程 
B 对 数组 元 素 的 写 入 ， 读 线程 C 可 能 看 得 到 ， 也 可 能 看 不 到 。JMM 不 保 
证 线程 B 的 写 入 对 读 线程 C 可 见 ， 因 为 写 线程 B 和 读 线程 C 之 间 存 在 数据 
竞争 ， 此 时 的 执行 结果 不 可 预知 。 








如 果 想 要 确保 读 线 程 C 看 到 写 线程 B 对 数组 元 素 的 号 入 ， 写 线程 BE 和 
读 线 程 C 之 间 需 要 使 用 同步 原 语 (lock 或 volatile〉 来 确保 内 存 可 见 性 。 


3.6.5 ”为 什么 final 引 用 不 能 从 构造 函数 内 “ 洲 出 ” 


前 面 我 们 提 到 过 ， 写 final 域 的 重 排序 规则 可 以 确保 : 在 引用 变量 为 
任意 线程 可 见 之 前 ， 该 引用 变量 指向 的 对 象 的 final 域 已 经 在 构造 冰 数 中 
被 正确 初始 化 过 了 。 其 实 ， 要 得 到 这 个 效果 ， 还 需要 一 个 保证 : 在 构造 
函数 内 部 ， 不 能 让 这 个 被 构造 对 象 的 引用 为 其 他 线程 所 见 ， 也 惑 是 对 象 
引用 不 能 在 构造 函数 中 “人 锡 出 ”。 为 了 次 明 问题 ， 让 我 们 来 看 下 面 的 示例 
代码 。 








public class FinalReferenceEscapeExample { 
final int 工 ; 
static FinalReferenceEscapeExample obj; 
public FinalReferenceEscapeExample () 
二 // 1 写 final 域 
obj = this; // 2 this 引 用 在 此 " 逸 出 " 











public static void writer() 
new FinalReferenceEscapeExample (); 


} 
public static void reader() { 
if (obj != null) { // 3 
int temp = obj.i; // 4 
} 
} 


} 


二 一 


线程 A 线程 B 线程 C 


构造 函数 开始 执行 


1: 写 fitnal 引 用 


2: 写 final 引 用 对 
象 的 成 员 域 

















StoreStore 屏 障 





时 间 
构造 函数 执行 结束 





3: 把 构造 对 象 
的 引用 赋值 给 引用 
变量 obj 








5: 读 对 象 引 用 cbj | 








LoadLoad 屏 障 | 











图 3-31 引用 型 fnal 的 执行 时 序 图 


假设 一 个 线程 A 执行 writer() 方 法 ， 男 一 个 线程 B 执 行 reader() 方 法 。 
这 里 的 操作 2 使 得 对 象 还 未 完成 构造 前 就 为 线程 B 可 见 。 即 使 这 里 的 操作 
2 是 构造 函数 的 最 后 一 步 ， 且 在 程序 中 操作 2 排 在 操作 1 后 面 ， 执 行 read() 














方法 的 线程 仍然 可 能 无 法 看 到 final 域 被 初始 化 后 的 值 ， 因 为 这 里 的 操作 
1 和 操作 2 之 间 可 能 被 重 排序 。 实 际 的 执行 时 序 可 能 如 图 3-32 所 示 。 





线程 A 线程 B 





构造 函数 开始 








obj = this; 
2: 被 构造 对 象 的 引用 
在 此 “和 逸 出 ” 



































if (obj != null) 
时 间 3: 读 取 不 为 null 的 对 象 
引用 a 
int temp = obj.i; 
4: 这 里 将 读 到 final 域 初 
台 化 之 前 的 值 
i= 1; Be 
1: 对 final 域 初始 化 
| 构造 函数 结束 








图 3-32 ”多 线程 执行 时 序 图 


从 图 3-32 可 以 看 出 : 在 构造 函数 返回 前 ， 说 构造 对 象 的 引用 不 能 大 
其 他 线程 所 见 ， 因 为 此 时 的 final 域 可 能 还 没有 钻 初 始 化 。 在 构造 冰 数 返 
回 后 ， 任 意 线程 都 将 保证 能 看 到 final 域 正确 初始 化 之 后 的 值 。 


3.6.6 final 语义 在 处 理 器 中 的 实现 


现在 我 们 以 X86 处 理 器 为 例 ， 说 明 final 语 义 在 处 理 器 中 的 具体 实 
现 。 


上 面 我 们 提 到 ， 写 final] 域 的 重 排序 规则 会 要 求 编译 器 在 final 域 的 写 
之 后 ， 构 造 函 数 return 之 前 插入 一 个 StoreStore 障 屏 。 读 final 域 的 重 排序 
规则 要 求 编 译 器 在 读 final 域 的 操作 前 面 插入 一 个 LoadLoad 屏 障 。 


由 于 X86 处 理 器 不 会 对 写 - 写 操作 做 重 排 序 ， 所 以 在 X86 处 理 器 中 ， 

写 final 域 需要 的 StoreStore 障 屏 会 被 省 略 挥 。 同 样 ， 由 于 X86 处 理 器 不 会 

对 存在 间接 依赖 关系 的 操作 做 重 排序 ， 所 以 在 X86 处 理 器 中 ， 读 final 域 

要 的 LoadLoad 屏 障 也 会 被 省 略 掉 。 也 就 是 说 ， 在 X86 处 理 器 中 ，final 
域 的 读 / 写 不 会 插入 任何 内 存 屏障 ! 








3.6.7 JSR-133 为 什么 要 增强 final 的 语义 


在 旧 的 Java 内 存 模型 中 ， 一 个 最 严重 的 缺陷 就 是 线程 可 能 看 到 final 
域 的 值 会 改变 。 比 如 ， 一 个 线程 当前 看 到 一 个 整 型 fnal 域 的 值 为 0《〈 还 
未 初始 化 之 前 的 默认 值 ) ， 过 一 段 时 间 之 后 这 个 线程 再 去 读 这 个 fina] 域 
的 值 时 ， 却 发 现 值 变 为 1〈 被 某 个 线程 初始 化 之 后 的 值 ) 。 节 第 见 的 例 
子 束 是 在 旧 的 Java 和 内存 模型 中 ，String 的 值 可 能 会 改变 。 


为 了 修补 这 个 漏洞 ，JSR-133 专 家 组 增强 了 final 的 语义 。 通 过 为 final 
域 增加 写 和 读 重 排序 规则 ， 可 以 为 Java 程 序 员 提 供 初 始 化 安全 保证 : 只 
要 对 象 是 正确 构造 的 《被 构造 对 象 的 引用 在 构造 函数 中 没有 “ 逸 出 ”) ， 
那么 不 需要 使 用 同步 〈 指 lock 和 volatile 的 使 用 ) 就 可 以 保证 任意 线程 都 
能 看 到 这 个 final 域 在 构造 函数 中 被 初始 化 之 后 的 值 。 


3.7 happens-before 


happens-before 是 JMM 最 核心 的 概念 。 对 应 Java 程 序 员 来 说 ， 理 解 
happens-before 是 理解 JMM 的 关键 。 


3.7.1 JMM 的 设计 


首先 ， 让 我 们 来 看 JMM 的 设计 意图 。 从 JMM 设 计 者 的 角度 ， 在 设 
计 JMM 时 ， 需 要 考虑 两 个 关键 因素 。 


` 程序 员 对 内 存 模型 的 使 用 。 程 序 员 希望 内 存 模 型 易于 理解 、 易 于 
编程 。 程 序 员 希望 基于 一 个 强 内 存 模 型 来 编写 代码 。 


. 编译 器 和 处 理 器 对 内 存 模型 的 实现 。 编 译 器 和 处 理 器 希望 内 存 模 
型 对 它们 的 束缚 越 少 越 好 ， 这 样 它 们 就 可 以 做 尽 可 能 多 的 优化 来 提高 性 


能 。 编 译 器 和 处 理 器 希望 实现 一 个 弱 内 存 模 型 。 





由 于 这 两 个 因素 互相 矛盾 ， 所 以 JSR-133 专 家 组 在 设计 JMM 时 的 核 
心目 标 就 是 找到 一 个 好 的 平衡 点 : 一 方面 ， 要 为 程序 员 提供 足够 强 的 内 
存 可 见 性 保证 ; 男 一 方面 ， 对 编译 器 和 处 理 器 的 限制 要 尽 可 能 地 放松 。 
下 面 让 我 们 来 看 JSR-133 是 如 何 实现 这 一 目标 的 。 








double pi = 3.14; //A 
double r = 1.0; // B 
double area = pi * r * r; // C 








上 面 计算 圆 的 面积 的 示例 代码 存在 3 个 happens-before 关 系 ， 如 下 。 


* A happens-before B。 


也 happens-before C。 
* A happens-before C。 


在 3 个 happens-before 关 系 中 ，2 和 3 是 必需 的 ， 但 1 是 不 必要 的 。 
此 ，JMM 把 happens-before 要 求 禁 止 的 重 排 序 分 为 了 下 面 两 类 。 


. 会 改变 程序 执行 结果 的 重 排序 。 


` 不 会 改变 程序 执行 结果 的 重 排 序 。 








JMM 对 这 两 种 不 同性 质 的 重 排序 ， 采 取 了 不 同 的 集 略 ， 如 下 。 


` 对 于 会 改变 程序 执行 结果 的 重 排 序 ，JMM 要 求 编译 器 和 处 理 器 必 
须 禁 止 这 种 重 排序 。 


“ 对 于 不 会 改变 程序 执行 结果 的 重 排序 ，JMM 对 编译 器 和 处 理 器 不 
做 要 求 (JMM 允 许 这 种 重 排 序 ) 。 


图 3-33 是 JMM 的 设计 示意 图 。 


区 程 序 员 本 程序 员 基 于 happens-before 
本 规则 提供 的 内 存 可 见 性 保证 


JMM 











\ 会 改变 程序 执 不 会 改变 程序 执 

' 行 结 果 的 重 排序 行 结果 的 重 排序 

和 WA 

' | 要 | | 要 | 

Gc 
| 禁 | | 禁 | 





程序 员 以 为 JMM 禁 止 了 这 种 重 排 
编译 器 处 理 需 序 ， 但 实际 上 JMM 并 没有 这 么 做 

















图 3-33 JMM 的 设计 示意 图 


从 图 3-33 可 以 看 出 两 点 ， 如 下 。 


JMM 向 程序 员 提 供 的 happens-before 规 则 能 满足 程序 员 的 需求 。 
JMM 的 happens-before 规 则 不 但 简单 易 懂 ， 而 且 也 向 程序 员 提 供 了 足够 强 


的 内 存 可 见 性 保证 (有些 内 存 可 见 性 保证 其 实 并 不 一 定 真实 存在 ， 比 如 
上 面 的 A happens-before B) 。 


JMM 对 编译 器 和 处 理 器 的 束缚 已 经 尽 可 能 少 。 从 上 面 的 分 析 可 以 
看 出 ，JMM 其 实 是 在 遵循 一 个 基本 原则 : 只 要 不 改变 程序 的 执行 结果 
( 指 的 是 单线 程 程序 和 正确 同步 的 多 线程 程序 ) ， 编 译 器 和 处 理 器 怎 





优化 都 行 。 例 如 ， 如 果 编 译 器 经 过 细致 的 分 析 后 ， 认 定 一 个 锁 只 会 被 单 
个 线程 访问 ， 那 么 这 个 锁 可 以 被 消除 。 再 如 ， 如 果 编 译 器 经 过 细致 的 分 


析 后 ， 认 定 一 个 volatile 变 量 只 会 被 单个 线程 访问 ， 那 么 编译 器 可 以 把 这 
个 volatile 变 量 当 作 一 个 普通 变量 来 对 待 。 这 些 优 化 既 不 会 改变 程序 的 执 
行 结果 ， 又 能 提高 程序 的 执行 效率 。 


3.7.2 ”happens-before 的 定义 


happens-before 的 概念 最 初 由 Leslie Lamport 在 其 一 篇 影响 深远 的 论 
文 (《Time，Clocks and the Ordering of Events in a Distributed 
System》 ) 中 提出 。Leslie Lamport 使 用 happens-before 来 定义 分 布 式 系 
统 中 事件 之 间 的 偏 序 关系 (partial ordering) 。Leslie Lamport 在 这 篇 论 
文中 给 出 了 一 个 分 布 式 算法 ， 该 算法 可 以 将 该 偏 序 关系 扩展 为 菜 种 全 序 
关系 。 


JSR-133 使 用 happens-before 的 概念 来 指定 两 个 操作 之 间 的 执行 顺 
序 。 由 于 这 两 个 操作 可 以 在 一 个 线程 之 内 ， 也 可 以 是 在 不 同 线程 之 间 。 
因此 ，JMM 可 以 通过 happens-before 关 系 向 程序 员 提 供 跨 线程 的 内 存 可 
见 性 保证 (如 果 A 线 程 的 写 操作 a 与 B 线 程 的 读 操 作 b 之 间 存 在 happens- 
before 关 系 ， 尺 管 a 操作 和 b 操 作 在 不 同 的 线程 中 执行 ， 但 JIMM 疝 程序 员 
保证 a 操作 将 对 b 操 作 可 见 〉。 











《JSR-133:Java Memory Model and Thread Specification》 对 happens- 
before 关 系 的 定义 如 下 。 


1) 如果 一 个 操作 happens-before 男 一 个 操作 ， 那 么 第 一 个 操作 的 执 
行 结果 将 对 第 二 个 操作 可 见 ， 而 且 第 一 个 操作 的 执行 顺序 排 在 第 二 个 操 
EH 








2) 两 个 操作 之 间 存 在 happens-before 关 系 ， 并 不 意味 着 Java 平 台 的 
具体 实现 必须 要 按照 happens-before 关 系 指定 的 顺序 来 执行 。 如 果 重 排序 
之 后 的 执行 结果 ， 与 按 happens-before 关 系 来 执行 的 结果 一 致 ， 那 么 这 种 
重 排序 并 不 非法 〈 也 就 是 说 ，JMM 人 允许 这 种 重 排序 ) 。 





上 面 的 1) 是 JMM 对 程序 员 的 承诺 。 从 程序 员 的 角度 来 说 ， 可 以 这 
样 理解 happens-before 关 系 : 如 果 A happens-before B， 那 么 Java 内 存 模型 
将 向 程序 员 保证 一 一 A 操 作 的 结果 将 对 B 可 见 ， 且 A 的 执行 顺序 排 在 B 之 
前 。 注 意 ， 这 只 是 Java 内 存 模型 向 程序 员 做 出 的 保证 ! 





上 面 的 2) 是 JMM 对 编译 器 和 处 理 器 重 排序 的 约束 原则 。 正 如 前 面 
所 言 ，JMM 其 实 是 在 遵循 一 个 基本 原则 : 只 要 不 改变 程序 的 执行 结 
( 指 的 是 单线 程 程序 和 正确 同步 的 多 线程 程序 ) ， 编 译 器 和 处 理 器 怎么 
优化 都 行 。JMM 这 么 做 的 原因 是 : 程序 员 对 于 这 两 个 操作 是 否 真 的 被 重 
排序 并 不 关心 ， 程 序 员 关心 的 是 程序 执行 时 的 语义 不 能 被 改变 《〈 即 执行 
结果 不 能 被 改变 ) 。 因 此 ，happens-before 关 系 本 质 上 和 as-if-serial 语 义 
是 一 回 事 。 














* as-if-setial 语 义 保证 单线 程 内 程序 的 执行 结果 不 被 改变 ，happens- 
before 关 系 保证 正确 同步 的 多 线程 程序 的 执行 结果 不 被 改变 。 


* as-if-serial 语 义 给 编写 单线 程 程序 的 程序 员 创 造 了 一 个 幻境 : 单线 


程 程序 是 按 程序 的 顺序 来 执行 的 。happens-before 关 系 给 编写 正确 同步 的 


多 线程 程序 的 程序 员 创造 了 一 个 幻境 : 正确 同步 的 多 线程 程序 是 按 


happens-befote 指 定 的 顺序 来 执行 的 。 


as-if-serial 语 义 和 happens-before 这 么 做 的 目的 ， 都 是 为 了 在 不 改变 
程序 执行 结果 的 前 提 下 ， 尽 可 能 地 提高 程序 执行 的 并 行 度 。 


3.7.3 ”happens-before 规 则 


《JSR-133:Java Memory Model and Thread Specification》 定 义 了 如 


下 happens-before 规 则 。 


1) 程序 顺序 规则 : 一 个 线程 中 的 每 个 操作 ，happens-before 于 该 线 
程 中 的 任意 后 续 操作 。 


2) 监视 器 锁 规则 : 对 一 个 锁 的 解锁 ，happens-before 于 随后 对 这 个 
锁 的 加 锁 。 


3) volatile 变 量规 则 : 对 一 个 volatile 域 的 写 ，happens-before 于 任意 


后 续 对 这 个 volatile 域 的 读 。 


4) 传递 性 : 如果 A happens-before B， 且 B happens-before C， 那 么 


A happens-before C。 


5) start() 规 则 :如果 线程 A 执行 操作 ThreadB.start()〈 启 动 线程 
B) ， 那 么 A 线程 的 ThreadB.start() 操 作 happens-before 于 线程 B 中 的 任意 
操作 。 


6) join0 规 则 : 如 果 线 程 A 执 行 操作 ThreadB.join0 并 成 功 返 回 ， 那 
么 线程 B 中 的 任意 操作 happens-before 于 线程 A 从 ThreadB.join0 操 作成 功 


返回 。 


这 里 的 规则 1) 、2) 、3) 和 4) 前 面 都 讲 到 过 ， 这 里 再 做 个 总 结 。 
由 于 2) 和 3) 情况 类 似 ， 这 里 只 以 1) 、3) 和 4) 为 例 来 说 明 。 图 3-34 
是 volatile 写 - 读 建立 的 happens-before 关 系 图 。 


线程 A 线程 B 


: 线程 A 修改 共享 


: 线程 A 写 volatile 





3: 线程 B 读 同一 


个 volatile 变 量 


程序 顺序 规则 和 
volatile 规 则 组 合 后 提 
供 的 happens-before 保 
证 : 1 happens-before 4 





图 3-34 happens-before 关 系 的 示意 图 


结合 图 3-34， 我 们 做 以 下 分 析 。 


.1 happens-before 2 和 3 happens-before 4 由 程序 顺序 规则 产生 。 由 于 
编译 器 和 处 理 器 都 要 遵守 as-if setial 语 义 ， 也 就 是 说 ，as-if setial 语 义 保证 
了 程序 顺序 规则 。 因 此 ， 可 以 把 程序 顺序 规则 看 成 是 对 as-if-serial 语 义 


的 “封装 ” 


.2 happens-before 3 是 由 volatile 规 则 产生 。 前 面 提 到 过 ， 对 一 个 
volatile 变 量 的 读 ， 总 是 能 看 到 (任意 线程 ) 之 前 对 这 个 volatile 变 量 最 后 


的 写 入 。 因 此 ，volatile 的 这 个 特性 可 以 保证 实现 volatile 规 则 。 


.1 happens-before 4 是 由 传递 性 规则 产生 的 。 这 里 的 传递 性 是 由 
volatile 的 内 存 屏 障 揪 入 策略 和 volatile 的 编译 器 重 排序 规则 共同 来 保证 
的 。 


下 面 我 们 来 看 startO 规 则 。 假 设 线程 A 在 执行 的 过 程 中 ， 通 过 执行 
ThreadB.startO 来 启动 线程 B; 同时 ， 假 设 线程 A 在 执行 ThreadB.start(O 之 
前 修改 了 一 些 共享 变量 ， 线 程 B 在 开始 执行 后 会 读 这 些 共享 变量 。 图 3- 


35 是 该 程序 对 应 的 happens-before 关 系 图 。 








线程 A 线程 B 





共享 变量 





2: 线程 A 执 行 


ThreadB .start() 


3: 线程 B 开 始 
执行 


线程 B 读 共 





程序 顺序 规则 和 
start() 规 则 组 合 后 提 
供 的 happens-before 保 
证 : 1 happens-before 4 


图 3-35” ”happens-before 关 系 的 示意 图 


在 图 3-35 中 ，1 happens-before 2 由 程序 顺序 规则 产生 。2 happens- 
before 4 由 start() 规 则 产生 。 根 据 传 递 性 ， 将 有 1 happens-before 4。 这 实 
意味 着 ， 线 程 A 在 执行 ThreadB.start() 之 前 对 共享 变量 所 做 的 修改 ， 接 下 
来 在 线程 B 开 始 执行 后 都 将 确保 对 线程 B 可 见 。 








下 面 我 们 来 看 join0 规 则 。 假 设 线程 A 在 执行 的 过 程 中 ， 通 过 执行 


ThreadB.join(0) 来 等 待 线程 B 终 止 ， 同 时 ， 假 设 线程 B 在 终止 之 前 修改 了 
一 些 共享 变量 ， 线 程 A 从 ThreadB.join0 返 回 后 会 读 这 些 共 享 变 量 。 图 3- 
36 是 该 程序 对 应 的 happens-before 关 系 图 。 


线程 A 线程 B 


1: 线程 A 执行 : ThreadB. 
jom() 


: 线程 B 终 止 


4: 线程 A 从 ThreadB. 
join() 操 作成 功 返 回 





join() 规 则 和 程序 
顺序 规则 组 合 后 提供 的 
happens-before 保 证 : 
2 happens-before 5 


图 3-36 ” happens-before 关 系 的 示意 图 


在 图 3-36 中 ，2 happens-before 4 由 join(0) 规 则 产生 ，4 happens-before 
5 由 程序 顺序 规则 产生 。 根 据 传递 性 规划， 将 有 2 happens-before 5。 这 意 


味 着 ， 线 程 A 执 行 操作 ThreadB.join0 并 成 功 返 回 后 ， 线 程 B 中 的 任意 操 
作 都 将 对 线程 A 可 见 。 


3.8 ”双重 检查 锁定 与 延迟 初始 化 











在 Java 多 线程 程序 中 ， 有 时 候 需 要 采用 延迟 初始 化 来 降低 初始 化 类 
和 创建 对 象 的 开销 。 双 重 检 查 锁 定 是 常见 的 延迟 初始 化 技术 ， 但 它 是 一 
个 错误 的 用 法 。 本 文 将 分 析 双 重 检查 锁定 的 错误 根源 ， 以 及 两 种 线程 安 
全 的 延迟 初始 化 方案 。 





3.8.1 双重 检查 锁定 的 由 来 





在 Java 程 序 中 ， 有 时 候 可 能 需要 推迟 一 些 高 开销 的 对 象 初 始 化 操 
作 ， 并 且 只 有 在 使 用 这 些 对 象 时 才 进 行 初 始 化 。 此 时 ， 程 序 员 可 能 会 条 
用 延迟 初始 化 。 但 要 正确 实现 线程 安全 的 延迟 初始 化 需要 一 些 技巧 ， 个 
则 很 容易 出 现 问 题 。 比 如 ， 下 面 是 非 线程 安全 的 延迟 初始 化 对 象 的 示例 
代码 。 











public class UnsafeLazyInitialization f{ 
private static Instance instance,; 
public static Instance getInstance() { 
if (instance == null) // 1: A 线程 执行 
instance = new Instance(); // 2: B 线 程 执行 
return instance; 





} 
} 








企 UnsafeLazyInitialization 类 中 ， 假 设 A 线程 执行 代码 1 的 同时 ，B 线 
程 执行 代码 2。 此 时 ， 线 程 A 可 能 会 看 到 instance 引 用 的 对 象 还 没有 完成 
初始 化 《出现 这 种 情况 的 原因 见 3.8.2 节 ) 。 


对 于 UnsafeLazyInitialization 类 ， 我 们 可 以 对 getInstance() 方 法 做 同步 
处 理 来 实现 线程 安全 的 延迟 初始 化 。 示 例 代 码 如 下 。 





public class SafeLazyInitialization { 
private static Instance Instance 
public synchronized static Instance getInstance() { 
If (instance == Null) 
instance = new Instance(); 
return instance; 


} 





由 于 对 getInstance() 方 法 做 了 同步 处 理 ，synchronized 将 导致 性 能 
销 。 如 末 getInstance() 方 法 修 多 个 线程 频繁 的 调用 ， 将 会 导致 程序 执行 
性 能 的 下 降 。 反 之 ， 如 果 getInstance() 方 法 不 会 被 多 个 线程 频繁 的 调 
用 ， 那 么 这 个 延迟 初始 化 方案 将 能 提供 令 人 满意 的 性 能 。 





在 早期 的 JVM 中 ，synchronized (甚至 是 无 竞争 的 synchronized) 存 
在 巨大 的 性 能 开销 。 因 此 ， 人 们 想 出 了 一 个 “聪明 ”的 技巧 : 双重 检查 锁 
定 〈Double-Checked Locking) 。 人 们 想 通 过 双重 检查 锁定 来 降低 同步 
的 开销 。 下 面 是 使 用 双重 检查 锁定 来 实现 延迟 初始 化 的 示例 代码 。 


























public class DoubleCheckedLocking { //1 
private static Instance instance,; // 2 
public static Instance getInstance() { // 3 
if (instance == null) { // 4: 第 一 次 检查 
synchronized (DoubleCheckedLocking.class) { // 5: 加 锁 
if (instance == null) // 6: 第 二 次 检查 
instance = new Instance(); // 7: 问 题 的 根源 出 在 这 里 
} // 8 
// 9 
return instance; // 10 
} // 11 
} 





如 上 面 代 码 所 示 ， 如 果 第 一 次 检查 instance 不 为 null， 那 么 就 不 需要 
执行 下 面 的 加 锁 和 初始 化 操作 。 因 此 ， 可 以 大 幅 降 低 synchronized 市 来 
的 性 能 开销 。 上 面 代码 表面 上 看 起 来 ， 似 乎 两 全 其 美 。 


` 多 个 线程 试图 在 同一 时 间 创 建 对 象 时 ， 会 通过 加 锁 来 保证 只 有 一 
个 线程 能 创建 对 象 。 


. 在 对 象 创建 好 之 后 ， 执 行 getInstance0 方 法 将 不 需要 获取 锁 ， 直 接 
返回 已 创建 好 的 对 象 。 





双重 检查 锁定 看 起 来 似乎 很 完美 ， 但 这 是 一 个 错误 的 优化 ! 在 线程 
执行 到 第 4 行 ， 代 码 读 取 到 instance 不 为 null 时 ，instance 引 用 的 对 象 有 可 
能 还 没有 完成 初始 化 。 


3.8.2 ”问题 的 根源 


前 面 的 双重 检查 锁定 示例 代码 的 第 7 行 (instance=new Singleton();) 
创建 了 一 个 对 象 。 这 一 行 代码 可 以 分 解 为 如 下 的 3 行 伪 代码 。 





memory = allocate(); // 1: 分 配对 象 的 内 存 空间 
ctorInstance(memory);  // 2: 初始 化 对 象 
instance = memory // 3: 设置 instance 指 向 刚 分 配 的 内 存 地址 





























上 上面 3 行 伪 代 码 中 的 2 和 3 之 间 ， 可 能 会 被 重 排序 〈 在 一 些 JII 编 译 器 
上 ， 这 种 重 排序 是 真实 发 生 的 ， 详 情 见 参考 文献 1 的 “Out-of-order 
writes” 部 分 ) 。2 和 3 之 间 重 排序 之 后 的 执行 时 序 如 下 。 











memory = allocate(); // 1: 分 配对 象 的 内 存 空间 

instance = memory; // 3: 设置 instance 指 向 刚 分 配 的 内 存 地 址 
// 注意 ， 此 时 对 象 还 没有 被 初始 化 ! 

ctorInstance(memory);  // 2: 初始 化 对 象 












































根据 《The Java Language Specification,Java SE 7 Edition》〔 后 文 简 
称 为 Java 语 言 规范 ) ， 所 有 线程 在 执行 Java 程 序 时 必须 要 遵守 intra- 
thread semantics。intra-thread semantics 保 证 重 排序 不 会 改变 单线 程 内 的 
程序 执行 结果 。 换 句 话 说 ，intra-thread semantics 允 许 那 些 在 单线 程 内 ， 
不 会 改变 单线 程 程序 执行 结果 的 重 排序 。 上 面 3 行 伪 代 码 的 2 和 3 之 间 虽 
然 被 重 排 序 了 ， 但 这 个 重 排 序 并 不 会 违反 intra-thread semantics。 这 个 重 
排序 在 没有 改变 单线 程 程序 执行 结果 的 前 提 下 ， 可 以 提高 程序 的 执行 性 


ZN 
CC 


为 了 更 好 地 理解 intra-thread semantics， 请 看 如 图 3-37 所 示 的 示意 图 
《假设 一 个 线程 A 在 构造 对 象 后 ， 立 即 访问 这 个 对 象 ) 。 


如 图 3-37 所 示 ， 只 要 保证 2 排 在 4 的 前 面 ， 即 使 2 和 3 之 间 重 排序 了 ， 


也 不 会 违反 intra-thread semantics。 


下 面 ， 再 让 我 们 但 看 多 线程 并 发 执行 的 情况 。 如 图 3-38 所 示 。 























线程 A 
1: 分 配对 象 的 内 存 
宇 间 
3: 设置 instance 指 A 
向 内 存 空间 ge 
时 间 “~ 虽然 这 里 2 和 3 
, 重 排 序 了 ， 但 是 
2: 初始 化 对 象 ao 上 保证 2 排 在 4 
的 前 面 执行 ， 单 
线程 内 的 执行 结 
4: 初次 访问 对 象 -=-- 有 果 陨 不 会 锌 改变 








图 3-37 ”线程 执行 时 序 图 
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4: A 线程 初次 访问 
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图 3-38 ”多 线程 执行 时 序 图 


由 于 单线 程 内 要 遵守 intra-thread semantics， 从 而 能 保证 A 线程 的 执 
行 结 果 不 会 被 改变 。 但 是 ， 当 线程 A 和 B 按 图 3-38 的 时 序 执行 时 ，B 线 程 
将 看 到 一 个 还 没有 被 初始 化 的 对 象 。 


回 到 本 文 的 主题 ，DoubleCheckedLocking 示 例 代 码 的 第 7 行 
(instance=new Singleton(0; ) 如 果 发 生 重 排序 ， 另 一 个 并 发 执行 的 线程 了 
就 有 可 能 在 第 4 行 判断 instance 不 为 null。 线 程 B 接 下 来 将 访问 instance 所 


引用 的 对 象 ， 但 此 时 这 个 对 象 可 能 还 没有 被 A 线程 初始 化 ! 表 3-6 是 这 个 
场景 的 具体 执行 时 序 。 


表 3-6 多 线程 执行 时 序 表 


线程 B 
Al: 分 配对 象 的 内 存 空间 





2 A3: 设置 instance 指向 内 存 空间 
t4 了 B2: 由 于 instance 不 为 null， 线程 B 将 访问 instance 引用 的 对 象 


t5 A2: 初始 化 对 象 





t6 A4: 访问 instance 引用 的 对 象 


这 里 A2 和 A3 虽 然 重 排序 了 ， 但 Java 内 存 模 型 的 intra-thread semantics 
将 确保 A2 一 定 会 排 在 A4 前 面 执行 。 因 此 ， 线 程 A 的 intra-thread semantics 
没有 改变 ， 但 A2 和 A3 的 重 排序 ， 将 导致 线程 B 在 B1 处 判断 出 instance 不 
为 空 ， 线 程 B 接 下 来 将 访问 instance 引 用 的 对 象 。 此 时 ， 线 程 B 将 会 访问 
到 一 个 还 未 初始 化 的 对 象 。 





在 知晓 了 问题 肥 生 的 根源 之 后 ， 我 们 可 以 想 出 两 个 办 法 来 实现 线程 
安全 的 延迟 初始 化 。 


1) 不 允许 2 和 3 重 排序 。 
2) 人 允许 2 和 3 重 排 序 ， 但 不 允许 其 他 线程 “看 到 ”这 个 重 排序 。 


后 文 介绍 的 两 个 解决 方案 ， 分 别 对 应 于 上 面 这 两 点 。 


3.8.3 ”基于 volatile 的 解决 方案 





对 于 前 面 的 基于 双重 检查 锁定 来 实现 延迟 初始 化 的 方案 〈 指 
DoubleCheckedLocking 示 例 代 码 ) ， 只 需要 做 一 点 小 的 修改 〈 把 instance 
声明 为 Volatile 型 ) ， 就 可 以 实现 线程 安全 的 延迟 初始 化 。 请 看 下 面 的 示 
例 代 码 。 





public class SafeDoubleCheckedLocking { 
private volatile static Instance instance,; 
public static Instance getInstance() { 


If (instance == nu]l1) { 
synchronized (SafeDoubleCheckedLocking.class) { 
if (instance == Null) 
instance = new Instance(); // instance 为 volatile， 现 在 没 证 
} 
} 
return instance; 
} 
} 





全 注音。 这 个 解决 方案 需要 JDK 5 或 更 高 版 本 (因为 从 JDK 5 开始 


使 用 新 的 JSR-133 内 存 模型 规范 ， 这 个 规范 增强 了 volatile 的 语义 ) 。 


当 声 明 对 象 的 引用 为 volatile 后 ，3.8.2 节 中 的 3 行 伪 代码 中 的 2 和 3 之 
间 的 重 排序 ， 在 多 线程 环境 中 将 会 被 蔡 止 。 上 面 示例 代码 将 按 如 下 的 时 
序 执行 ， 如 图 3-39 所 示 。 
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图 3-39 ”多 线程 执行 时 序 图 





这 个 方案 本 质 上 是 通过 禁止 图 3-39 中 的 2 和 3 之 间 的 重 排序 ， 来 保证 
线程 安全 的 延迟 初始 化 。 


3.8.4 基于 类 初始 化 的 解决 方案 


JVM 在 类 的 初始 化 阶段 〈 即 在 Class 被 加 载 后 ， 且 被 线程 使 用 之 
前 ) ， 会 执行 类 的 初始 化 。 在 执行 类 的 初始 化 期 间 ，JVM 会 去 获取 一 个 
锁 。 这 个 锁 可 以 同步 多 个 线程 对 同一 个 类 的 初始 化 。 


基于 这 个 特性 ， 可 以 实现 另 一 种 线程 安全 的 延迟 初始 化 方案 〈 这 个 
方案 被 称 之 为 Initialization On Demand Holder idiom) 。 





public class InstanceFactory { 
private static class InstanceHolder { 
public static Instance instance = new Instance(); 


public static Instance getInstance() { 
return InstanceHolder.instance ; // 这 里 将 导致 InstanceHolder 类 被 初始 化 























假设 两 个 线程 并 发 执行 getInstance() 方 法 ， 下 面 是 执行 的 示意 图 ， 
如 图 3-40 所 示 。 


假设 线程 A 获取 到 了 锁 ， 
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2: 初始 化 对 象 

















即使 2 和 3 之 间 存在 重 排 
， 序 ， 但 线程 B 无 法 “看 到 ” | 
， 这 个 重 排 序 


图 3-40 ”两 个 线程 并 发 执行 的 示意 图 


这 个 方案 的 实质 是 : 允许 3.8.2 节 中 的 3 行 伪 代 码 中 的 2 和 3 重 排序 ， 
但 不 允许 非 构造 线程 《这 里 指 线程 B)“ 看 到 ”这 个 重 排序 。 


初始 化 一 个 类 ， 包 括 执行 这 个 类 的 静态 初始 化 和 初始 化 在 这 个 类 中 
声明 的 静态 字段 。 根 据 Java 语 言 规范 ， 在 首次 发 生 下 列 任意 一 种 情况 
时 ， 一 个 类 或 接口 类 型 T 将 被 立即 初始 化 。 


1) T 是 一 个 类 ， 而 且 一 个 T 类 型 的 实例 被 创建 。 
2) TIT 是 一 个 类 ， 且 T 中 声明 的 一 个 静态 方法 被 调用 。 


3) I 中 声明 的 一 个 静态 字段 被 赋值 。 


4) T 中 声明 的 一 个 静态 字段 被 使 用 ， 而 且 这 个 字段 不 是 一 个 常量 字 


段 。 


5) TT 是 一 个 顶级 类 〈Top Level Class， 见 Java 语 言 规范 的 87.6) ， 而 
且 一 个 断言 语句 和 伦 套 在 T 内 部 被 执行 。 





在 InstanceFactory 示 例 代 人 码 中 ， 首 次 执行 getInstance() 方 法 的 线程 将 
导致 InstanceHolder 类 被 初始 化 (符合 情况 4) 。 





由 于 Java 语 言 是 多 线程 的 ， 多 个 线程 可 能 在 同一 时 间 和 党 试 去 初始 化 
同一 个 类 或 接口 (比如 这 里 多 个 线程 可 能 在 同一 时 刻 调用 getInstance() 
方法 来 初始 化 InstanceHolder 类 ) 。 因 此 ， 在 Java 中 初始 化 一 个 类 或 者 接 
口 时 ， 需 要 做 细致 的 同步 处 理 。 


Java 语 言 规范 规定 ， 对 于 每 一 个 类 或 接口 C， 都 有 一 个 唯一 的 初始 
化 锁 LC 与 之 对 应 。 从 Ca 到 LC 的 映 风 ， 由 JVM 的 具体 实现 去 自由 实现 。 
JVM 在 类 初始 化 期 间 会 获取 这 个 初始 化 锁 ， 并 且 每 个 线程 至 少 获取 一 次 
锁 来 确保 这 个 类 已 经 被 初始 化 过 了 (事实 上 ，Java 语 言 规范 允许 JVM 的 
具体 实现 在 这 里 做 一 些 优化 ， 见 后 文 的 说 明 ) 。 











对 于 类 或 接口 的 初始 化 ，Java 语 言 规范 制定 了 精巧 而 复杂 的 类 初始 
化 处 理 过 程 。Java 初 始 化 一 个 类 或 接口 的 处 理 过程 如 下 《这 里 对 类 初始 
化 处 理 过 程 的 说 明 ， 省 略 了 与 本 文 无 关 的 部 分 ; 同时 为 了 更 好 的 说 明 类 
初始 化 过 程 中 的 同步 处 理 机 制 ， 笔 者 人 为 的 把 类 初始 化 的 处 理 过 程 分 为 


了 5 个 阶段 〉》。 


第 1 阶段 : 通过 在 Class 对 象 上 同步 〈 即 获取 Class 对 象 的 初始 化 
锁 ) ， 来 控制 类 或 接口 的 初始 化 。 这 个 获取 锁 的 线程 会 一 直 等 待 ， 直 到 
当前 线程 能 够 获取 到 这 个 初始 化 锁 。 








假设 Class 对 象 当 前 还 没有 被 初始 化 (初始 化 状态 state， 此 时 被 标记 
为 state=noInitializa-tion) ， 且 有 两 个 线程 A 和 了 B 试 图 同时 初始 化 这 个 
Class 对 象 。 图 3-41 是 对 应 的 示意 图 。 
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初始 化 锁 





BI1 


表 3-7 是 这 个 示意 图 的 说 明 。 


图 3-41 类 初始 化 一 一 第 1 阶段 


表 3-7 类 初始 化 一 一 第 1 阶段 的 执行 时 序 表 


时 间 线程 B 
Al: 尝试 获取 Class 对 象 的 初始 化 锁 。 这 里 假 | Bl1: 尝试 获取 Class 对 象 的 初始 化 锁 ， 由 于 线程 A 
设 线程 A 获取 到 了 初始 化 锁 获取 到 了 锁 ， 线 程 B 将 一 直 等 待 获取 初始 化 锁 
A2 : 线程 A 看 到 线程 还 未 被 初始 化 (因为 读 
t2 取 到 state == noInitialization )， 线 程 设 并 state = 
initializing 
t3 A3: 线程 A 释放 初始 化 锁 





第 2 阶段 : 线程 A 执行 类 的 初始 化 ， 同 时 线程 B 在 初始 化 锁 对 应 的 


condition 上 等 待 。 
表 3-8 是 这 个 示意 图 的 说 明 。 
表 3-8 ”类 初始 化 一 一 第 2 阶段 的 执行 时 序 表 


: 获取 到 初始 化 锁 


: 读 取 到 state = initializing 
: 释放 初始 化 锁 
: 在 初始 化 锁 的 condition 中 等 待 
















执行 类 的 表 态 初始 化 
和 初始 化 类 中 声明 的 静 
态 字 段 。 下 面 是 初始 化 
instance 的 过 程 。1: 分 配 
内 存 空间 。3: 赋值 给 引用 
变量 。2: 初始 化 对 象 。 
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图 3-42 ”类 初始 化 一 一 第 2 阶段 


第 3 阶段 线程 A 设 置 state=initialized， 然 后 唤醒 在 condition 中 等 待 
的 所 有 线程 。 
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图 3-43 ”类 初始 化 一 一 第 3 阶段 


表 3-9 是 这 个 示意 图 的 说 明 。 


表 3-9 ”类 初始 化 一 一 第 3 阶段 的 执行 时 序 表 





时 间 线程 B 
tl B1: 获取 到 初始 化 锁 
2 B2: 读 取 到 state = initializing 
B3: 释放 初始 化 锁 
{4 B4: 在 初始 化 锁 的 condition 中 等 待 


第 4 阶段 : 线程 B 结 束 类 的 初始 化 处 理 。 


a ee ee B4 of ® ) 
(、 线 程 B ) 人 
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图 3-44 ”类 初始 化 一 一 第 4 阶段 


表 3-10 是 这 个 示意 图 的 说 明 。 


表 3-10 ”类 初始 化 一 一 第 4 阶段 的 执行 时 序 表 


线程 B 
B3: 释放 初始 化 锁 


t2 : 读 取 到 state = initialized B4: 线程 B 的 类 初始 化 处 理 过 程 完成 
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图 3-45 ”多 线程 执行 时 序 图 


线程 A 在 第 2 阶段 的 Al 执行 类 的 初始 化 ， 并 在 第 3 阶段 的 A4 释 放 初 始 
化 锁 ; 线程 B 在 第 4 阶段 的 B1 获 取 同 一 个 初始 化 锁 ， 并 在 第 4 阶段 的 B4 之 
后 才 开 始 访问 这 个 类 。 根 据 Java 内 存 模型 规范 的 锁 规 则 ， 这 里 将 存在 如 





下 的 happens-before 关 系 。 


这 个 happens-before 关 系 将 保证 : 线程 A 执 行 类 的 初始 化 时 的 写 入 操 
作 《〈 执 行 类 的 静态 初始 化 和 初始 化 类 中 声明 的 静态 字段 ) ， 线 程 B 一 定 
能 看 到 。 


第 5 阶段 线程 C 执 行 类 的 初始 化 的 处 理 。 


C4 是 二 
线程 C 人 色光 








a state = initialized 
Class 对 和 象 的 








初始 化 锁 


图 3-46 ”类 初始 化 一 一 第 5 阶段 
表 3-11 是 这 个 示意 图 的 说 明 。 


表 3-11 类 初始 化 一 一 第 5 阶段 的 执行 时 序 表 


时 间 线程 BB 
tl C1l: 获取 初始 化 锁 
t2 C2: 读 取 到 state = initialized 
t3 C3: 释放 初始 化 锁 
t4 C4: 线程 C 的 类 初始 化 处 理 过 程 完成 


在 第 3 阶段 之 后 ， 类 已 经 完成 了 初始 化 。 因 此 线程 C 在 第 5 阶段 的 类 
初始 化 处 理 过 程 相对 简单 一 些 〈 前 面 的 线程 A 和 B 的 类 初始 化 处 理 过 程 
都 经 历 了 两 次 锁 获 取 - 锁 释放 ， 而 线程 C 的 类 初始 化 处 理 只 需要 经 历 一 次 
锁 获 取 - 锁 释放 ) 。 


线程 A 在 第 2 阶段 的 Al 执行 类 的 初始 化 ， 并 在 第 3 阶段 的 A4 释 放 锁 ; 


线程 C 在 第 5 阶段 的 C1 获 取 同 一 个 锁 ， 并 在 在 第 5 阶段 的 C4 之 后 才 开 始 访 
问 这 个 类 。 根 据 Java 内 存 模 型 规范 的 锁 规 则 ， 将 存在 如 下 的 happens- 
before 关 系 。 





这 个 happens-before 关 系 将 保证 : 线程 A 执行 类 的 初始 化 时 的 写 入 操 
作 ， 线 程 C 一 定 能 看 到 。 


© 注意 ”这 里 的 condition 和 state 标 记 是 本 文 虚构 出 来 的 。Java 语 言 
规范 并 没有 硬性 规定 一 定 要 使 用 condition 和 state 标 记 。JVM 的 具体 实现 


只 要 实现 类 似 功 能 即 可 。 


© Java 语 言 规范 允许 Java 的 具体 实现 ， 优 化 类 的 初始 化 处 理 
过 程 (对 这 里 的 第 5 阶段 做 优化 ) ， 具 体 细节 参见 Java 语 言 规范 的 12.4.2 
A 
让 


O 


线程 A 线程 C 


执行 类 的 静态 初 
台 化 和 初始 化 类 中 
声明 的 静态 字段 








时 间 获取 Class 对 象 的 锁 





结束 类 初始 化 处 理 过 
程 ， 然 后 访问 这 个 类 





图 3-47 ”多 线程 执行 时 序 图 


通过 对 比 基 于 volatile 的 双重 检查 锁定 的 方案 和 基于 类 初始 化 的 方 
案 ， 我 们 会 及 现 基于 类 初始 化 的 方案 的 实现 代码 更 简洁 。 但 基于 volatile 
的 双重 检查 锁定 的 方案 有 一 个 额外 的 优势 ， 除了 可 以 对 静态 字段 实现 延 
迟 初 始 化 外 ， 还 可 以 对 实例 字段 实现 延 人 运 初 始 化 。 











字段 延迟 初始 化 降低 了 初始 化 类 或 创建 实例 的 开销 ， 但 增加 了 访问 
被 延迟 初始 化 的 字段 的 开销 。 在 大 多 数 时 候 ， 正 常 的 初始 化 要 优 于 延迟 
初始 化 。 如 采 确 实 需 要 对 实例 字段 使 用 线程 安全 的 延迟 初始 化 ， 请 使 用 
上 面 介 绍 的 基于 volatile 的 延迟 初始 化 的 方案 ， 如 果 确 实 需 要 对 静态 字段 








使 用 线程 安全 的 延迟 初始 化 ， 请 使 用 上 面 介 绍 的 基于 类 初始 化 的 方案 。 


3.9 ” Java 内 存 模 型 综述 


前 面 对 Java 内 存 模型 的 基础 知识 和 内 存 模型 的 具体 实现 进行 了 说 
明 。 下 面 对 Java 内 存 模型 的 相关 知识 做 一 个 总 结 。 


3.9.1 ”处理 器 的 内 存 模 型 


顺序 一 致 性 内 存 模型 是 一 个 理论 参考 模型 ，JMM 和 处 理 器 内 存 模型 
在 设计 时 通 第 会 以 顺序 一 致 性 内 存 模型 为 参照 。 在 设计 时 ，JMM 和 处 理 
器 内 存 横 型 会 对 顺序 一 致 性 模型 做 一 些 放 松 ， 因 为 如 果 完 全 按照 顺序 一 
致 性 模型 来 实现 处 理 右 和 JMM， 那 么 很 多 的 处 理 器 和 编译 器 优化 都 要 被 
茶 止 ， 这 对 执行 性 能 将 会 有 很 大 的 影 啊 。 








根据 对 不 同类 型 的 读 / 写 操作 组 合 的 执行 顺序 的 放松 ， 可 以 把 常见 
处 理 占 的 内 存 模型 划分 为 如 下 几 种 类 型 。 


放松 程序 中 写 - 读 操作 的 顺序 ， 由 此 产生 了 Total Store Ordering 内 
存 模 型 (简称 为 TSO) 。 


. 在 上 面 的 基础 上 ， 继 续 放 松 程序 中 写 - 写 操作 的 顺序 ， 由 此 产生 
了 Partial Store Oftdet 内 存 模型 (简称 为 PSBO) 。 


` 在 前 面 两 条 的 基础 上 ， 继 续 放松 程序 中 读 - 写 和 读 - 读 操作 的 顺 
序 ， 由 此 产生 了 Relaxed Memory Order 内 存 模 型 (简称 为 RMO) 和 


PowetPC 内 存 模 型 。 


注意 ， 这 里 处 理 器 对 读 / 写 操作 的 放松 ， 是 以 两 个 操作 之 间 不 存在 
数据 依赖 性 为 前 提 的 《因为 处 理 器 要 遵守 as-if-serial 语 义 ， 处 理 喜 不 会 


对 存在 数据 依赖 性 的 两 个 内 存 操作 做 重 排序 ) 。 
表 3-12 展 示 了 常见 处 理 器 内 存 模型 的 细节 特征 如 下 。 


表 3-12 处理 器 内 存 模 型 的 特征 表 


内 存 模型 Load-Load 和 可 以 可 时 Te 
名 称 处 理 器 重 排序 重 排 序 。 | “09d-Store | 读 取 到 其 他 | 读 取 到 当前 

重 排 序 。 | 处 理 器 的 写 | 处 理 器 的 写 
TO | reTsoxg | YY | | | 
?so | saemo | YY | YY | | 
mm | | ww | w | ww | | 
PowerPC | Powere | YY | YY | YY | YY _ 





从 表 3-12 中 可 以 看 到 ， 所 有 处 理 费 内 存 模型 都 允许 写 - 读 重 排序 ， 原 
因 在 第 1 章 已 经 说 明 过 : 它们 都 使 用 了 写 缓存 区 。 写 缓存 区 可 能 导致 写 - 
读 操作 重 排 序 。 同 时 ， 我 们 可 以 看 到 这 些 处 理 右 内 存 模型 都 允许 更 早 读 
到 当前 处 理 器 的 号 ， 原 因 同 样 是 因为 写 缓存 区 。 由 于 写 缓存 区 仅 对 当前 
处 理 葛 可 见 ， 这 个 特性 导致 当前 处 理 占 可 以 比 其 他 处 理 器 先 看 到 临时 保 
存在 自己 写 缓存 区 中 的 写 。 























表 3-12 中 的 各 种 处 理 器 内 存 模型 ， 从 上 到 下 ， 模 型 由 强 变 弱 。 越 是 
退 求 性 能 的 处 理 器 ， 和 内 存 模型 设计 得 会 越 弱 。 因 为 这 些 处 理 器 希望 内 存 
模型 对 它们 的 束缚 越 少 越 好 ， 这 样 它们 束 可 以 做 尽 可 能 多 的 优化 来 提高 
性 能 。 


由 于 常见 的 处 理 器 内 存 模型 比 JMM 要 弱 ，Java 编 译 器 在 生成 字 节 码 
时 ， 会 在 执行 指令 序列 的 适当 位 置 插入 内 存 屏 障 来 限制 处 理 器 的 重 排 


序 。 同 时 ， 由 于 各 种 处 理 器 内 存 模型 的 强 弱 不 同 ， 为 了 在 不 同 的 处 理 器 
平台 向 程序 员 展示 一 个 一 致 的 内 存 模型 ，JMM 在 不 同 的 处 理 器 中 需要 插 
入 的 内 存 屏 障 的 数量 和 种 类 也 不 相同 。 图 3-48 展 示 了 JMM 在 不 同 处 理 器 
内 存 模型 中 需要 插入 的 内 存 屏障 的 示意 





JMM 拼 蔽 了 不 同 处 理 器 内 存 模 型 的 到 异 ， 它 在 不 同 的 处 理 器 平台 之 
上 为 Java 程 序 员 呈 现 了 一 个 一 致 的 内 存 模型 。 











TSO 内 存 模型 
> StoreLoad Barriers 
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PSO 内 存 模 型 StoreLoad Bar mm > 


























sparc-PSO | | 程 \ 
» | 
> StoreStore Barriers < 一 一 | 序 | 
| 员 | 
> storeLoad Barriers 
RMO/PowerPC 
内 存 模型 
StoreStore > 
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PowerPC > LoadStore 3 


2 Load-Load > 


图 3-48 JMM 插 入 内 存 屏障 的 示意 图 























3.9.2 ”各 种 内 存 模型 之 间 的 关系 


JMM 是 一 个 语言 级 的 内 存 模型 ， 处 理 器 内 存 模型 是 硬件 级 的 内 存 模 
型 ， 顺 序 一 致 性 内 存 模型 是 一 个 理论 参考 模型 。 下 面 是 语言 内 存 模型 、 
处 理 器 内 存 模型 和 顺序 一 致 性 内 存 模型 的 强 弱 对 比 示意 图 ， 如 图 3-49 所 


人 钞 。 








从 图 中 可 以 看 出 : 常见 的 4 种 处 理 器 内 存 模 型 比 常用 的 3 中 语言 内 存 
模型 要 弱 ， 处 理 器 内 存 模型 和 语言 内 存 模型 都 比 顺序 一 致 性 内 存 模型 要 
弱 。 同 处 理 咒 内存 模型 一 样 ， 越 是 追求 执行 性 能 的 语言 ， 内 存 模 型 设计 
得 会 越 弱 。 


3.9.3 JMM 的 内 存 可 见 性 保证 





按 程序 类 型 ，Java 程 序 的 内 存 可 见 性 保证 可 以 分 为 下 列 3 类 。 


. 单线 程 程序 。 单 线程 程序 不 会 出 现 内 存 可 见 性 问题 。 编 译 器 、 
runtime 和 处 理 器 会 共同 确保 单线 程 程序 的 执行 结果 与 该 程序 在 顺序 一 臻 
性 模型 中 的 执行 结果 相同 。 


正确 同步 的 多 线程 程序 。 正 确 同步 的 多 线程 程序 的 执行 将 具有 顺 
序 一 致 性 (程序 的 执行 结果 与 该 程序 在 顺序 一 致 性 内 存 模型 中 的 执行 结 
果 相同 ) 。 这 是 JMM 关 注 的 重点 ，JMM 通 过 限制 编译 器 和 处 理 器 的 重 排 
序 来 为 程序 员 提 供 内 存 可 见 性 保证 。 

未 同步 /未 正确 同步 的 多 线程 程序 。JMM 为 它们 提供 了 最 小 安全 
性 保障 : 线程 执行 时 读 取 到 的 值 ， 要 么 是 之 前 某 个 线程 写 入 的 值 ， 要 么 


是 默认 值 (0、 null、 false) O 


最 
好 








最 好 < 执行 性 能 ”最 关 


图 3-49 ”各 种 CPU 内 存 模 型 的 强 弱 对 比 示 意图 








注意 ， 最 小 安全 性 保障 与 64 位 数据 的 非 原 子 性 写 并 不 予 盾 。 它 们 是 
两 个 不 同 的 概念 ， 它 们 “发 生 * 的 时 间 扣 也 不 同 。 最 小 安全 性 保证 对 象 默 
认 初 始 化 之 后 《设置 成 员 域 为 0、null 或 false) ， 才 会 被 任意 线程 使 用 。 
最 小 安全 性 “有 发生” 在 对 象 被 任意 线程 使 用 之 前 。64 位 数据 的 非 原 子 性 
写 “ 发 生 * 在 对 象 被 多 个 线程 使 用 的 过 程 中 〈 写 共享 变量 ) 。 当 发 生 问 题 
时 《处理 器 B 看 到 仪 仅 补 处 理 器 A“ 写 了 一 半 ” 的 无 效 值 ) ， 这 里 虽然 处 
理 费 B 读 取 到 一 个 被 写 了 一 半 的 无 效 值 ， 但 这 个 值 仍然 是 处 理 絮 A 写 入 





， 中 不 过 是 人 处理 占 A 还 没有 写 完 而 已 。 最 小 安全 性 保证 线程 读 取 到 的 
值 ， 要 么 是 之 前 茶 个 线程 写 入 的 值 ， 要 么 是 默认 值 "0、null、false) 。 

但 最 小 安全 性 并 不 保证 线程 读 取 到 的 值 ， 一 定 是 茶 个 线程 写 完 后 的 值 。 

最 小 安全 性 保证 线程 读 取 到 的 值 不 会 无 中 生 有 的 冒 出 来 ， 但 并 不 保证 线 
程 读 取 到 的 值 一 定 是 正确 的 。 


到 











图 3-50 展 示 了 这 3 类 程序 在 JMM 中 与 在 顺序 一 致 性 内 存 模型 中 的 执 
行 结果 的 异同 。 








只 要 多 线程 程序 是 正确 同步 的 ，JMM 保 证 该 程序 在 任意 的 处 理 器 平 
台 上 的 执行 结果 ， 与 该 程序 在 顺序 一 致 性 内 存 模型 中 的 执行 结束 一 致 。 





3.9.4 JSR-133 对 旧 内 存 模型 的 修补 


JSR-133 对 JDK 5 之 前 的 旧 内 存 模型 的 修补 主要 有 两 个 。 


. 增强 volatile 的 内 存 语 义 。 旧 内 存 模型 允许 volatile 变 量 与 普通 变量 
重 排序 。JSR-133 严 格 限制 volatile 变 量 与 普通 变量 的 重 排序 ， 使 volatile 的 
写 - 读 和 锁 的 释放 -获取 具有 相同 的 内 存 语义 。 


. 增强 final 的 内 存 语 义 。 在 旧 内 存 模型 中 ， 多 次 读 取 同 一 个 final 变 
量 的 值 可 能 会 不 相同 。 为 此 ，JSR-133 为 final 增 加 了 两 个 重 排序 规则 。 在 
保证 final 引 用 不 会 从 构造 函数 内 逸 出 的 情况 下 ，final 具 有 了 初始 化 安全 
性 。 


执行 结果 相同 








Ss | 单线 程 程序 | _ 一、 | 大小 必 
一 一 竺 一 要- 


”执行 结果 相同 、 


有 正确 同步 的 
一 一 一 < | 多 线程 程序 




















未 同步 /未 正 
i 确 同 步 的 多 
线程 程序 
执行 结果 二 果 
不 可 预知 可 能 不 可 预知 


图 3-50 3 类 程序 的 执行 结果 的 对 比 图 


3.10” ”本章 小 结 


本 章 对 Java 内 存 模型 做 了 比较 全 面 的 解读 。 和 希望 读者 阅读 本 章 之 
后 ， 对 Java 内 存 模型 能 够 有 一 个 比较 深入 的 了 解 ， 同 时 ， 也 和 希望 本 章 可 
帮助 读者 解决 在 Java 并 发 编程 中 经 常 遇 到 的 各 种 内 存 可 见 性 问题 。 


第 4 章 Java 并 发 编程 基础 


Java 从 道生 开始 就 明智 地 选择 了 内 置 对 多 线程 的 支持 ， 这 使 得 Java 
语言 相 比 同一 时 期 的 其 他 语言 具有 明显 的 优势 。 线 程 作为 操作 系统 调度 
的 最 小 单元 ， 多 个 线程 能 够 同时 执行 ， 这 将 显著 提升 程序 性 能 ， 在 多 核 
环境 中 表现 得 更 加 明显 。 但 是 ， 过 多 地 创建 线程 和 对 线程 的 不 当 管理 也 
容易 造成 问题 。 本 章 将 着 重 介绍 Java 并 发 编程 的 基础 知识 ， 从 启动 一 个 
线程 到 线程 间 不 同 的 通信 方式 ， 最 后 通过 简单 的 线程 池 示例 以 及 应 用 
简单 的 Web 服务 器 ) 来 串联 本 章 所 介绍 的 内 容 。 





4.1 线程 简介 


4411 什么 喜人 盘 程 


现代 操作 系统 在 运行 一 个 程序 时 ， 会 为 其 创建 一 个 进程 。 例 如 ， 局 
动 一 个 Java 程 序 ， 操 作 系 统 就 会 创建 一 个 Java 进 程 。 现 代 操 作 系 统 调度 
的 最 小 单元 是 线程 ， 也 叫 轻 量 级 进程 〈Light Weight Process) ， 在 一 个 
进程 里 可 以 创建 多 个 线程 ， 这 些 线程 都 拥有 各 自 的 计数 器 、 堆 栈 和 局 部 
变量 等 属性 ， 并 且 能 够 访问 共享 的 内 存 变 量 。 处 理 器 在 这 些 线程 上 高 速 
切换 ， 让 使 用 者 感觉 到 这 些 线程 在 同时 执行 。 


一 个 Java 程 序 从 main() 方 法 开始 执行 ， 然 后 按照 既定 的 代码 逻辑 执 
行 ， 看 似 没 有 其 他 线程 参与 ， 但 实际 上 Java 程 序 天 生 就 是 多 线程 程序 ， 
因为 执行 main() 方 法 的 是 一 个 名 称 为 main 的 线程 。 下 面 使 用 JMX 来 查看 
一 个 普通 的 Java 程 序 包含 哪些 线程 ， 如 代码 清单 4-1 所 示 。 


代码 清单 4-1 MultiThread.java 





public class MultiThread{ 
public static void main(String[] args) { 
// 获取 Java 线 程 管理 MXBean 
ThreadMXBean threadMXBean = Managenen Factory: yot rhroachXpean(); 
// 不 需要 获取 同步 的 nonitor 和 synchronizer 信 息 ， 仅 获取 线程 和 线程 堆栈 信息 
ThreadInfo[] threadInfos = threadMXBean. diinpAL1Threads (false, false); 
// 遍历 线程 信息 ， 仅 打印 线程 ED 和 线程 名 称 信息 
for (ThreadInfo threadInfo : threadInfos) { 
System.out.printin("[" + threadInfo,getThreadId() + "] " + threadInfo， 
getThreadName( )); 























} 





输出 如 下 所 示 〔 输 出 内 容 可 能 不 同 〉。 








[4] Signal Dispatcher  // 分 发 处 理发 送 给 JVM 信 号 的 线程 


























[3] Finalizer // 调用 对 象 finalize 方 法 的 线程 
[2] Reference Handler  ”// 清除 Reference 的 线程 
[1] main // _ main 线程， 用 户 程序 入 口 




















可 以 看 到 ， 一 个 Java 程 序 的 运行 不 仅仅 是 main0 方 法 的 运行 ， 而 是 
main 线 程 和 多 个 其 他 线程 的 同时 运行 。 





4.1.2 ”为 什么 要 使 用 多 线程 


执行 一 个 简单 的 “Hello,World!”*"， 却 启动 了 那么 多 的 “无 关 ” 线 程 ， 是 
不 是 把 简单 的 问题 复杂 化 了 ? 当然 不 是 ， 因 为 正确 使 用 多 线程 ， 总 是 能 
够 给 开发 人 员 带 来 显著 的 好 处 ， 而 使 用 多 线程 的 原因 主要 有 以 下 几 点 。 

















(1) 更 多 的 处 理 吉 核心 


随 痢 处 理 喜 上 的 核心 数量 越 来 越 多 ， 以 及 超 线程 技术 的 广泛 运用 ， 
现在 大 多 数 计算 机 都 比 以 往 更 加 擅长 并 行 计 算 ， 而 处 理 器 性 能 的 提升 方 
式 ， 也 从 更 高 的 主 频 同 更 多 的 核心 发 展 。 如 何 利用 好 处 理 器 上 的 多 个 核 
心 也 成 了 现在 的 主要 问题 。 





线程 是 大 多 数 操作 系统 调度 的 基本 单元 ， 一 个 程序 作为 一 个 进程 来 
运行 ， 程 序 运行 过 程 中 能 够 创建 多 个 线程 ， 而 一 个 线程 在 一 个 时 刻 只 能 
运行 在 一 个 处 理 器 核心 上 。 试 想 一 下 ， 一 个 单线 程 程序 在 运行 时 只 能 使 
用 一 个 处 理 器 核心 ， 那 么 再 多 的 处 理 器 核心 加 入 也 无 法 显著 提升 该 程序 
的 执行 效率 。 相 反 ， 如 果 该 程序 使 用 多 线程 技术 ， 将 计算 逻辑 分 配 到 多 
个 处 理 器 核心 上 ， 束 会 显著 减少 程序 的 处 理 时 间 ， 并 且 随 着 更 多 处 理 吕 
核心 的 加 入 而 变 得 更 有 效率 。 





(2) 更 快 的 啊 应 时 间 





有 时 我 们 会 编写 一 些 较为 复杂 的 代码 《〈 这 里 的 复杂 不 是 次 复杂 的 算 
法 ， 而 是 复杂 的 业务 负 辑 ) ， 例如， 一 笔 订单 的 创建 ， 它 包括 插入 订单 
数据 、 生 成 订单 快照 、 发 送 邮 件 通 知 卖 家 和 记录 货品 销售 数量 等 。 用 户 
从 单 击 “订购 ?按钮 开始 ， 就 要 等 待 这 些 操 作 全 部 完成 才能 看 到 订购 成 功 
的 结果 。 但 是 这 么 多 业务 操作 ， 如 何 能 够 让 其 更 快 地 完成 呢 ? 








在 上 面 的 场景 中 ， 可 以 使 用 多 线程 技术 ， 即 将 数据 一 致 性 不 强 的 操 
作 沽 发 给 其 他 线程 处 理 〈 也 可 以 使 用 消 恩 队列 ) ， 如 生成 订单 快照 、 发 
送 邮件 等 。 这 样 做 的 好 处 是 啊 应 用 户 请 求 的 线程 能 够 尽 可 能 快 地 处 理 完 
成 ， 缩 短 了 响应 时 间 ， 提 升 了 用 户 体验 。 





(3) 更 好 的 编程 模型 


Java 为 多 线程 编程 提供 了 民 好 、 考 客 并 且 一 致 的 编程 模型 ， 使 开发 
员 能 够 更 加 专注 于 问题 的 解决 ， 即 为 所 遇 到 的 问题 建立 合适 的 模型 ， 
而 不 是 绞 尽 脑 汁 地 考虑 如 何 将 其 多 线程 化 。 一 旦 开发 人 员 建 立 好 了 模 
型 ， 稍 做 修改 总 是 能 够 方便 地 映射 到 Java 提 供 的 多 线程 编程 模型 上 。 


4.1.3 ”线程 优先 级 


现代 操作 系统 基本 采用 时 分 的 形式 调度 运行 的 线程 ， 操 作 系 统 会 分 
出 一 个 个 时 间 片 ， 线 程 会 分 配 到 知 干 时 间 片 ， 当 线程 的 时 间 片 用 完了 惑 
会 发 生 线程 调度 ， 并 等 待 着 下 次 分 配 。 线 程 分 配 到 的 时 间 片 多 少 也 就 决 
定 了 线程 使 用 处 理 占 资源 的 多 少 ， 而 线程 优先 级 就 是 决定 线程 需要 多 或 
者 少 分 配 一 些 处 理 韦 资源 的 线程 属性 。 








在 Java 线 程 中 ， 通 过 一 个 整 型 成 员 变 量 priority 来 控制 优先 级 ， 优 先 
级 的 范围 从 1~10， 在 线程 构建 的 时 候 可 以 通过 setPriority(int) 方 法 来 修改 
优先 级 ， 默 认 优先 级 是 5， 优 先 级 高 的 线程 分 配 时 间 厂 的 数量 要 多 于 优 
先 级 低 的 线程 。 设 置 线程 优先 级 时 ， 针 对 频 蚂 阻 窟 (休眠 或 者 W/O 操 
作 ) 的 线程 需要 设置 较 高 优先 级 ， 而 仿 重 计算 (需要 较 多 CPU 时 间或 者 
偏 运算 ) 的 线程 则 设置 较 低 的 优先 级 ， 确 保 处 理 占 不 会 被 独占 。 在 不 同 
的 JVM 以 及 操作 系统 上 ， 线 程 规划 会 存在 差异 ， 有 些 操作 系统 甚至 会 忽 
上 略 对 线程 优先 级 的 设 定 ， 示 例如 代码 清单 4-2 所 示 。 


代码 清单 4-2 Priority.java 





public class Priority { 
private static volatile boolean notStart = true,; 
private static volatile boolean notEnd = true; 
public static void main(String[] args) throws Exception { 
List<Job> jobs = new ArrayList<Job>(); 
for (int i = 0; i < 10; i++) { 
int priority = i < 5 Thread.MIN PRIORITY : Thread.MAX_ PRIORITY, 
Job job = new Job(priority); 


jobs.add(job); 

Thread thread = new Thread(job, "Thread:" + i); 
thread.setPriority(priority); 

thread. start(); 


notStart = false; 

TimeUnit.SECONDS. sleep(10); 

notEnd = false; 

for (Job job : jobs) { 
System,out,.println("Job Priority : " + job.priority + ", 
Count : " + job.jobCount); 

} 


static class Job implements Runnable { 
private int priority; 
private long jobCount; 
public Job(int priority) { 
this.priority = priority; 


} 
public void run() { 
while (notStart) { 
Thread .yield( ); 


} 

while (notEnd) { 
Thread .yield( ); 
jobCount++; 


ww 
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» 


运行 该 示例 ， 在 笔者 机 器 上 对 应 的 输出 如 下 。 





Count : 1259592 
Count : 1260717 
Count : 1264510 
Job Priority : Count : 1251897 
Job Priority : Count : 1264060 
Job Priority : 10, Count : 1256938 
Job Priority : 10, Count : 1267663 
Job Priority : 10, Count : 1260637 
Job Priority : 10, Count : 1261705 
Job Priority : 10, Count : 1259967 


Job Priority : 
Job Priority : 
Job Priority : 


~ 


~ ~ 


PR FF FF 


~ 





从 输出 可 以 看 到 线程 优先 级 没有 和 生效， 优先 级 1 和 优先 级 10 的 Job 计 
数 的 结果 非常 相近 ， 没 有 明显 差距 。 这 表示 程序 正确 性 不 能 依赖 线程 的 
优先 级 高 低 。 


全 注意 战 程 优先 级 不 能 作为 程序 正确 性 的 依赖 ， 因 为 操作 系统 
可 以 完全 不 用 理会 Java 线 程 对 于 优先 级 的 设 定 。 笔 者 的 环境 为 : Mac OS 
X 10.10，Java 版 本 为 1.7.0_ 71， 经 过 笔者 验证 该 环境 下 所 有 Java 线 程 优先 
级 均 为 5 (通过 jstack 查 看 ) ， 对 线程 优先 级 的 设置 会 被 忽略 。 另 外 ， 举 
试 在 Ubuntu 14.04 环 境 下 运行 该 示例 ， 输 出 结果 也 表示 该 环境 忽略 了 线 
程 优先 级 的 设置 。 


4.1.4 ”线程 的 状态 


Java 线 程 在 运行 的 生命 周期 中 可 能 处 于 表 4-1 所 示 的 6 种 不 同 的 状 
态 ， 在 给 定 的 一 个 时 刻 ， 线 程 只 能 处 于 其 中 的 一 个 状态 。 


表 4-1 Java 线程 的 状态 


状态 名 称 说 明 
NEW 初始 状态 ， 线 程 被 构建 ， 但 是 还 没有 调用 start0 方法 
RUNNABLE 运行 状态 ，Java 线程 将 操作 系统 中 的 就 绪 和 运行 两 种 状态 笼统 地 称 作 “运行 中 ” 
BLOCKED 阻塞 状态 ， 表 示 线 程 阻塞 于 锁 


等 待 状态 ， 表 示 线 程 进 入 等 待 状态 ， 进 入 该 状态 表示 当前 线程 需要 等 待 其 他 线程 


WAITING i pe 

做 出 一 些 特定 动作 (通知 或 中 断 ) 
TIME WAITING 超时 等 待 状态 ， 该 状态 不 同 于 WAITING， 它 是 可 以 在 指定 的 时 间 自 行 返回 的 
TERMINATED 终止 状态 ， 表 示 当 前 线程 已 经 执行 完毕 


下 面 我 们 使 用 jstack 工 具 《〈 可 以 选择 打开 终端 ， 键 入 jstack 或 者 到 
JDK 安 装 目 录 的 bn 目录 下 执行 命令 ) ， 尝 试 查 看 示例 代码 运行 时 的 线程 
信息 ， 更 加 深入 地 理解 线程 状态 ， 示 例如 代码 清单 4-3 所 示 。 


代码 清单 4-3 ThreadState.java 





public class ThreadState { 
public static void main(String[] args) { 
new Thread(new Timewaiting (), "TimewaitingThread").start(); 
new Thread(new Waiting(), "WaitingThread").start(); 
// 使 用 两 个 Blocked 线 程 ， 一 个 获取 锁 成 功 ， 另 一 个 被 阻塞 
new Thread(new Blocked(), "BlockedThread-1").start(); 
new Thread(new Blocked(), "BlockedThread-2").start(); 














} 
// 该 线程 不 断 地 进行 睡眠 
static class Timewaiting implements Runnable { 
@Override 
public void run() { 
while (true) { 
SleepUtils.second(100); 





} 
// 该 线程 在 Waiting .class 实 例 上 等 待 
static class Waiting implements Runnable { 
@Override 
public void run() { 
while (true) { 
synchronized (Waiting.class) { 
try { 
Waiting.class.wait( ); 
} catch (InterruptedException e) { 
e.printStackTrace( ); 
} 


} 


} 
// 该 线程 在 Blocked .class 实 例 上 加 锁 后 ， 不 会 释放 该 锁 
static class Blocked implements Runnable { 
public void run() { 
Synchronized (Blocked.class) { 
while (true) { 
SleepUtils.second(100); 
} 





上 述 示例 中 使 用 的 SleepUtils 如 代码 清单 4-4 所 示 。 


代码 清单 4-4 SleepUtils.java 





public class SleepUtils { 
public static final void second(long seconds) { 
try { 
TimeUnit .SECONDS. sleep(seconds); 
} catch (InterruptedException e) { 


} 


ww 





运行 该 示例 ， 打 开 终 端 或 者 命令 提示 符 ， 键 入 “jps”"， 输 出 如 下 。 





611 

935 Jps 

929 ThreadState 
270 





可 以 看 到 运行 示例 对 应 的 进程 ID 是 929， 接 着 再 键入 “jstack 
929”( 这 里 的 进程 ID 需要 和 读者 自己 键入 jps 得 出 的 ID 一 致 ) ， 部 分 输 
出 如 下 所 示 。 





// BlockedThread -2 线程 阻塞 在 获取 Blocked.class 示 例 的 锁 上 
"BlockedThread-2" prio=5 tid=0x00007feacb05d000 nid=0x5d03 waiting for monitor 
entry [9x900000010fd58000] 

java.lang.Thread.State: BLOCKED (on object monitor) 
// BlockedThread-1 线 程 获 取 到 了 Blocked .class 的 锁 
"BlockedThread-1" prio=5 tid=0x00007feacb05a000 nid=0x5b03 waiting on condition 
[Ox000000010fc55000] 

java.lang.Thread.State: TIMED WAITING (sleeping) 
// WaitingThread 线 程 在 Waiting 实 例 上 等 待 
"WaitingThread" prio=5 tid=0x00007feacb059800 nid=0x5903 in Object.wait() 
[Ox000000010fb52000] 

java.lang.Thread.State: WAITING (on object monitor) 
// TimewaitingThread 线 程 处 于 超时 等 待 
"TimewaitingThread"” prio=5 tid=0x00007feacb058800 nid=0x5703 waiting on condition 
[0x000000010fa4f000] 

java.lang.Thread.State: TIMED_WAITING (Sleeping) 

















通过 示例 ， 我 们 了 解 到 Java 程 序 运行 中 线程 状态 的 具体 含义 。 线 程 
在 自身 的 生命 周期 中 ， 并 不 是 固定 地 处 于 菜 个 状态 ， 而 是 随 着 代码 的 执 
行 在 不 同 的 状态 之 间 进 行 切换 ，Java 线 程 状态 变迁 如 图 4-1 示 。 
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图 4-1 Java 线程 状态 变迁 


由 图 4-1 中 可 以 看 到 ， 线 程 创 建 之 后 ， 调 用 start() 方 法 开始 运行 。 妆 
线程 执行 wait(O 方 法 之 后 ， 线 程 进入 等 竺 状态。 进入 等 待 状态 的 线程 需 
要 依靠 其 他 线程 的 通知 才能 够 返回 到 运行 状态 ， 而 超时 等 待 状态 相当 于 
在 等 待 状态 的 基础 上 增加 了 超时 限制 ， 也 就 是 超时 时 间 到 达 时 将 会 
到 运行 状态 。 当 线程 调用 同步 方法 时 ， 在 没有 获取 到 锁 的 情况 下 ， 线 程 
将 会 进入 到 阻塞 状态 。 线 程 在 执行 Runnable 的 run() 方 法 之 后 将 会 进入 到 
终止 状态 。 


略 注意 Java 将 操作 系统 中 的 运行 和 就 绪 两 个 状态 合并 称 为 运行 


状态 。 阻 塞 状 态 是 线程 阻塞 在 进入 synchronized 关 键 字 修饰 的 方法 或 代码 
块 (获取 锁 ) 时 的 状态 ， 但 是 阻塞 在 java.concuttent 包 中 Lock 接 口 的 线程 
状态 却 是 等 待 状态 ， 因 为 java.concurrent 包 中 Lock 接 口 对 于 阻塞 的 实现 均 


使 用 了 LockSupport 类 中 的 相关 方法 。 


4.1.5 “Daemon 线程 





Daemon 线 程 是 一 种 支持 型 线程 ， 因 为 它 主要 被 用 作 程 序 中 后 台 调 
度 以 及 文 持 性 工作 。 这 意味 着 ， 当 一 个 Java 虚 拟 机 中 不 存在 非 Daemon 线 
程 的 时 候 ，Java 虚 拟 机 将 会 退出 。 可 以 通过 调用 Thread.setDaemon(true) 


将 线程 设置 为 Daemon 线 程 。 





全 注 意 “ Dacmon 必 性 需要 在 启动 线程 之 前 设置 ， 不 能 在 启动 线程 


Daemon 线 程 被 用 作 完 成 支持 性 工作 ， 但 是 在 Java 虚 拟 机 退出 时 
Daemon 线 程 中 的 finally 块 并 不 一 定 会 执行 ， 示 例如 代码 清单 4-5 所 示 。 


代码 清单 4-5 ”Daemon.java 





public class Daemon { 
public static void main(String[] args) { 
Thread thread = new Thread(new DaemonRunner(), "DaemonRunner"); 
thread.setDaemon(true); 
thread. start(); 


static class DaemonRunner implements Runnable { 
@Override 
public void run() { 
try { 
SleepUtils.second(10); 
} finally { 
System.out.printin("DaemonThread finally run."); 


运行 Daemon 程 序 ， 可 以 看 到 在 终端 或 者 命令 提示 符 上 没有 任何 输 
出 。main 线 程 〈 非 Daemon 线 程 ) 在 启动 了 线程 DaemonRunner 之 后 随 着 
main 方 法 执行 完毕 而 终止 ， 而 此 时 Java 虚 拟 机 中 已 经 没有 非 Daemon 线 
程 ， 虚 拟 机 需要 退出 。Java 虚 拟 机 中 的 所 有 Daemon 线 程 都 需要 立即 终 
止 ， 因 此 DaemonRunner 立 即 终 止 ， 但 是 DaemonRunner 中 的 finally 块 并 
没有 执行 。 


四 注意 “在 构建 Daemon 线 程 时 ， 不 能 依靠 nally 块 中 的 内 容 来 确 
保 执 行 关闭 或 清理 资源 的 逻辑 。 


4.2 ”局 动 和 终止 线程 


在 前 面 章 市 的 示例 中 通过 调用 线程 的 start0) 方 法 进行 启动 ， 随 看 
run(0 方 法 的 执行 完毕 ， 线 程 也 随 之 终止 ， 大 家 对 此 一 定 不 会 陌生 ， 下 面 
将 详细 介绍 线程 的 局 动 和 终止 。 


4.2.1 构造 线程 


在 运行 线程 之 前 首先 要 构造 一 个 线程 对 象 ， 线 程 对 象 在 构造 的 时 候 
需要 提供 线程 所 需要 的 属性 ， 如 线程 所 属 的 线程 组 、 线 程 优先 级 、 是 否 
是 Daemon 线 程 等 信息 。 代 码 清单 4-6 所 示 的 代码 摘自 java.lang.Thread 中 
对 线程 进行 初始 化 的 部 分 。 





代码 清单 4-6 Thread.java 





private void init(ThreadGroup g, Runnable target, String name, Jong stackSize, 
AccessControlContext acc) { 
If (name == nul1) { 
throw new NullpPointerException("name cannot be null"); 


} 

// 当前 线程 就 是 该 线程 的 父 线程 

Thread parent = currentThread () 
this.group = 9g; 

// 将 daemon、priority 属 性 设置 为 父 线程 的 对 应 属性 
this,daemon = parent.isDaemon(); 
this.priority = parent ,getPriority( )， 
this.name = name.toCharArray(); 
this.target = target,; 
setpriority(priority); 

// 将 父 线程 的 InheritableThreadLocal 复 制 过 来 
if (parent.inheritableThreadLocals != null) 
this,.inheritableThreadLocals=ThreadLocal.createInheritedMap(parent. 
inheritableThreadLocals); 

// 分 配 一 个 线程 ID 

tid = nextThreadID() ， 

















Ti 





























在 上 述 过 程 中 ， 一 个 新 构造 的 线程 对 象 是 由 其 parent 线 程 来 进行 空 
间 分 配 的 ， 而 child 线 程 继承 了 parent 是 否 为 Daemon、 优 先 级 和 加 载 资 源 
的 contextClassLoader 以 及 可 继承 的 ThreadLocal， 同 时 还 会 分 配 一 个 唯一 
的 ID 来 标识 这 个 child 线 程 。 至 此 ， 能 够 运行 的 线程 对 象 就 初始 化 好 





了 ， 在 堆 内 存 中 们 


4.2.2 ”启动 线程 


线程 对 象 在 初始 化 完成 之 后 ， 调 用 start(0) 方 法 束 可 以 局 动 这 个 线 
程 。 线 程 start(0) 方 法 的 含义 是 : 当前 线程 〈 即 parent 线 程 ) 同步 告知 Java 
虚拟 机 ， 只 要 线程 规划 器 空 亲 ， 应 立即 局 动 调用 start(0) 方 法 的 线程 。 


人 i 意 启动 一 个 线程 前 ， 最 好 为 这 个 线程 设置 线程 名 称 ， 因 为 
这 样 在 使 用 jstack 分 析 程 序 或 者 进行 问题 排查 时 ， 就 会 给 开发 人 员 提供 一 


些 提 示 ， 自 定义 的 线程 最 好 能 够 起 个 名 字 。 


\ 


4.2.3 理解 中 断 


中 上 断 可 以 理解 为 线程 的 一 个 标识 位 属性 ， 它 表示 一 个 运行 中 的 线程 
是 否 被 其 他 线程 进行 了 中 断 操 作 。 中 断 好 比 其 他 线程 对 该 线程 打 了 个 招 
呼 ， 其 他 线程 通过 调用 该 线程 的 interrupt0 方 法 对 其 进行 中 断 操作 。 


线程 通过 检查 自 喘 是 售 被 中 断 来 进行 啊 应 ， 线 程 通过 方法 
isInterrupted0 来 进行 判断 是 否 被 中 断 ， 也 可 以 调用 静态 方法 
Thread.interrupted() 对 当前 线程 的 中 断 标识 位 进行 复位 。 如 果 该 线程 已 经 
处 于 终结 状态 ， 即 使 该 线程 被 中 断 过 ， 在 调用 该 线程 对 象 的 
isInterruptedO 时 依旧 会 返回 false。 





从 Java 的 API 中 可 以 看 到 ， 许 多 声明 抛 出 InterruptedException 的 方法 
(例如 Thread.sleep(long millis) 方 法 ) 这 些 方法 在 抛 出 
InterruptedException 之 前 ，Java 虚 拟 机 会 先 将 该 线程 的 中 断 标识 位 清 
除 ， 然 后 抛 出 InterruptedException， 此 时 调用 isInterrupted() 方 法 将 会 返 
回 false。 


在 代码 清单 4-7 所 示 的 例子 中 ， 首 先 创建 了 两 个 线程 ，SleepThread 
和 BusyThread， 前 者 不 停 地 睡眠 ， 后 者 一 直 运 行 ， 然 后 对 这 两 个 线程 分 
别 进行 中 断 操 作 ， 观 察 二 者 的 中 断 标 识 位 。 


代码 清单 4-7 Interrupted.java 





public class Interrupted { 
public static void main(String[] args) throws Exception { 
// sleepThread 不 停 的 尝试 睡眠 
Thread sleepThread = new Thread(new SleepRunner(), "SleepThread"); 
SleepThread ,setDaemon(true ) ; 
// busyThread 不 停 的 运行 
Thread busyThread = new Thread(new BusyRunner(), "BusyThread"); 
busyThread. setDaemon(true); 
SleepThread ,start(); 
busyThread. start(); 





TimeUnit.SECONDS. sleep(5); 

SleepThread ,interrupt(); 

busyThread ,interrupt()， 

System.out.printilin("SleepThread interrupted is " + SleepThread .isInterrupte 
System,out,.printJln("BusyThread interrupted is " + busyThread ,isInterrupted(， 
// 防止 SleepThread 和 busyThread 立 刻 退 出 

SleepUtils.second(2); 





} 


static class SleepRunner implements Runnable { 
@Override 
public void run() { 
while (true) { 
SleepUtils.second(10); 
3 


} 


static class BusyRunner implements Runnable { 
@Override 
public void run() { 
while (true) { 


} 





输出 如 下 。 





SleepThread interrupted is false 
BusyThread interrupted is true 





从 结果 可 以 看 出 ， 抛 出 InterruptedException 的 线程 SleepThread， 其 
中 断 标 识 位 被 清除 了 ， 而 一 直 忙 碌 运作 的 线程 BusyThread， 中 断 标 识 位 
没有 被 清除 。 


4.2.4 ”过 期 的 suspend()、resume() 和 stop() 


大 家 对 于 CD 机 肯定 不 会 陌生， 如 果 把 它 播放 音乐 比 作 一 个 线程 的 
运作 ， 那 么 对 音乐 播放 做 出 的 暂停 、 恢 复 和 停止 操作 对 应 在 线程 Thread 
的 API 就 是 suspendO0、resumeO 和 stopO)。 


在 代码 清单 4-8 所 示 的 例子 中 ， 创 建 了 一 个 线程 PrintThread， 它 以 1 
秒 的 频率 进行 打印 ， 而 主线 程 对 其 进行 暂停 、 恢 复 和 停止 操作 。 





代码 清单 4-8 。 Deprecated.java 





public class Deprecated { 

public static void main(String[] args) throws Exception { 
DateFormat format = new SimpleDateFormat("HH:mm:ss"); 
Thread printThread = new Thread(new Runner(), "PrintThread"); 
printThread.setDaemon(true); 
printThread. start(); 
TimeUnit.SECONDS. sleep(3); 
// 将 PrintThread 进 行 暂 停 ， 输 出 内 容 工 作 停止 
printThread. suspend( ); 
System,out,.println("main suspend PrintThread at " + format.format(new Date(, 
TimeUnit .SECONDS. sleep(3); 
// 将 PrintThread 进 行 恢复 ， 输 出 内 容 继续 
printThread ,resume() ， 
System,out.println("main resume PrintThread at " + format ,format(new Date(), 
TimeUnit,. SECONDS .Sleep(3)， 
// 将 PrintThread 进 行 终止 ， 输 出 内 容 停止 
printThread. stop(); 
System.out.printilin("main stop PrintThread at " + format.format(new Date())), 
TimeUnit .SECONDS. sleep(3); 





















































static class Runner implements Runnable { 
@Override 
public void run() { 
DateFormat format = new SimpleDateFormat("HH:mm:ss"); 
while (true) { 
System.out.printin(Thread.currentThread().getName() + " Run at "™ + 
format ,format(new Date() ) )， 
SleepUtils.second(1); 





输出 如 下 《输出 内 容 中 的 时 间 与 示例 执行 的 具体 时 间 相 关 ) 。 





PrintThread Run at 17:34:36 
PrintThread Run at 17:34:37 
PrintThread Run at 17:34:38 

main Suspend PrintThread at 17:34:39 
main resume PrintThread at 17:34:42 
PrintThread Run at 17:34:42 
PrintThread Run at 17:34:43 
PrintThread Run at 17:34:44 

main stop PrintThread at 17:34:45 





在 执行 过 程 中 ，PrintThread 运 行 了 3 秒 ， 随 后 被 暂停 ，3 秒 后 恢复 ， 


最 后 经 过 3 秒 被 终止 。 


通过 示例 的 输出 可 以 看 到 ，suspend()、resume() 和 stop0 方 法 完成 了 
线程 的 暂停 、 恢 复 和 终止 工作 ， 而 且 非 常 * 人 性 化 ”。 但 是 这 些 API 是 过 
期 的 ， 也 就 是 不 建议 使 用 的 。 


不 建议 使 用 的 原因 主要 有 : 以 suspend() 方 法 为 例 ， 在 调用 后 ， 线 程 
不 会 释放 已 经 占有 的 资源 (比如 锁 ) ， 而 是 占有 着 资源 进入 睡眠 状态 ， 
这 样 容 易 引 发 死 锁 问题 。 同 样 ，stop0 方 法 在 终结 一 个 线程 时 不 会 保证 
线程 的 资源 正常 释放 ， 通 常 是 没有 给 予 线程 完成 资源 释放 工作 的 机 会 ， 
因此 会 导致 程序 可 能 工作 在 不 确定 状态 下 。 














© 注意 ” 正 因 为 suspend0)、resume( 和 stop0 方 法 带 来 的 副作用 ， 这 
些 方法 才 被 标注 为 不 建议 使 用 的 过 期 方法 ， 而 暂停 和 恢复 操作 可 以 用 后 


面 提 到 的 等 待 / 通 知 机 制 来 替代 。 


4.2.5 “安全 地 终止 线程 


在 4.2.3 贡 中 提 到 的 中 断 状态 是 线程 的 一 个 标识 位 ， 而 中 断 操 作 是 一 
种 简便 的 线程 间 交 互 方式 ， 而 这 种 交互 方式 最 适合 用 来 取消 或 停止 任 

除了 中 断 以 外 ， 还 可 以 利用 一 个 boolean 变 量 来 控制 是 否 需要 停止 任 
务 并 终止 该 线程 。 




















在 代码 清单 4-9 所 示 的 例子 中 ， 创 建 了 一 个 线程 CountThread， 它 不 
断 地 进行 变量 累加 ， 而 主线 程 尝 试 对 其 进行 中 断 操 作 和 停止 操作 。 





代码 清单 4-9 Shutdown.java 





public class Shutdown { 
public static void main(String[] args) throws Exception { 
Runner one = new Runner(); 
Thread countThread = new Thread(one, "CountThread"); 
countThread.start(); 
// 睡眠 1 秒 ，main 线 程 对 CountThread 进 行 中 断 ， 使 CountThread 能 够 感知 中 断 而 结 
TimeUnit.SECONDS. sleep(1); 
countThread.interrupt(); 
Runner two = new Runner(); 
countThread = new Thread(two, "CountThread"); 
countThread.start(); 
// 睡眠 1 秒 ，main 线 程 对 Runner two 进 行 取消 ， 使 CountThread 能 够 感知 on 为 false 而 结束 
TimeUnit .SECONDS .Sleep(1)， 
two.cancel(); 












































private static class Runner implements Runnable { 
private long i; 
private volatile boolean on = true; 
@Override 
public void run() { 
while (on && !Thread.currentThread().isInterrupted())t{ 
I++ ， 


System.out.printilin("Count i = " + 1); 


public void cancel() { 
on = false; 
} 





输出 结果 如 下 所 示 《〈 输 出 内 容 可 能 不 同 ) 。 





Count 工 = 543487324 
Count i = 540898082 





示例 在 执行 过 程 中 ，main 线 程 通 过 中 断 操作 和 cancel0 方 法 均 可 使 
CountThread 得 以 终止 。 这 种 通过 标识 位 或 者 中 断 操 作 的 方式 能 够 使 线 
程 在 终止 时 有 机 会 去 清理 资源 ， 而 不 是 武断 地 将 线程 停止 ， 因 此 这 种 终 
止 线 程 的 做 法 显得 更 加 安全 和 优雅 。 


4.3 线程 间 通 信 


线程 开始 运行 ， 拥 有 自己 的 栈 空间 ， 就 如 同一 个 脚本 一 样 ， 按 照 既 
定 的 代码 一 步 一 步 地 执行 ， 直 到 终止 。 但 是 ， 每 个 运行 中 的 线程 ， 如 果 
仅仅 是 孤立 地 运行 ， 那 么 没有 一 点 儿 价值 ， 或 者 说 价值 很 少 ， 如 果 多 个 
线程 能 够 相互 配合 完成 工作 ， 这 将 会 带 来 巨大 的 价值 。 


4.3.1 volatile 和 synchronized 关 键 字 








Java 文 持 多 个 线程 同时 访问 一 个 对 象 或 者 对 象 的 成 员 变 量 ， 由 于 每 
个 线程 可 以 拥有 这 个 变量 的 拷贝 (虽然 对 象 以 及 成 员 变量 分 配 的 内 存 是 
在 共 至 内 存 中 的 ， 但 是 每 个 执行 的 线程 还 是 可 以 拥有 一 份 拷贝 ， 这样 做 
的 目的 是 加 速 程序 的 执行 ， 这 是 现代 多 核 处 理 絮 的 一 个 显著 特性 ) ， 所 
以 程序 在 执行 过 程 中 ， 一 个 线程 看 到 的 变量 并 不 一 定 是 最 新 的 。 


关键 字 volatile 可 以 用 来 修饰 字段 (成 员 变 量 ) ， 就 是 告知 程序 任何 
对 该 变量 的 访问 均 需 要 从 共享 内 存 中 获取 ， 而 对 它 的 改变 必须 同步 刷新 
回 共享 内 存 ， 它 能 保证 所 有 线程 对 变量 访问 的 可 见 性 。 























举 个 例子 ， 定 义 一 个 表示 程序 是 否 运行 的 成 员 变 量 boolean 
on=true， 那 么 另 一 个 线程 可 能 对 它 执 行 关闭 动作 〈on=false) ， 这 里 涉 
及 多 个 线程 对 变量 的 访问 ， 因 此 需要 将 其 定义 成 为 volatile boolean on 二 
true， 这 样 其 他 线程 对 它 进行 改变 时 ， 可 以 让 所 有 线程 感知 到 变化 ， 因 
为 所 有 对 on 变量 的 访问 和 修改 都 需要 以 共享 内 存 为 准 。 但 是 ， 过 多 地 使 
用 volatile 是 不 必要 的 ， 因 为 它 会 降低 程序 执行 的 效率 。 








关键 字 synchronized 可 以 修饰 方法 或 者 以 同步 块 的 形式 来 进行 使 
用 ， 它 主要 确保 多 个 线程 在 同一 个 时 刻 ， 只 能 有 一 个 线程 处 于 方法 或 者 
司 步 块 中 ， 它 保证 了 线程 对 变量 访问 的 可 见 性 和 排他 性 。 





在 代码 清单 4-10 所 示 的 例子 中 ， 使 用 了 同步 块 和 同步 方法 ， 通 过 使 
用 javap 工 具 查 看 生成 的 class 文 件 信 息 来 分 析 synchronized 关 键 字 的 实现 
细节 ， 示 例如 下 。 


代码 清单 4-10 ”Synchronized.java 





public class Synchronized { 
public static void main(String[] args) { 
// 对 Synchronized Class 对 象 进行 加 锁 
synchronized (Synchronized.class) { 


























} 
// 静态 同步 方法 ， 对 Synchronized Class 对 象 进行 加 锁 





m(); 
} 
public static synchronized void m() { 
} 








在 Synchronized.class 同 级 目录 执行 javap-v Synchronized.class， 部 分 
相关 输出 如 下 所 示 : 





public static void main(java.lang.string[]); 
// 方法 修饰 符 ， 表示: public staticflags: ACC_PUBLIC, ACC_STATIC 




















Code: 
stack=2, locals=1, args_size=1 
0: ldc #1 // class com/murdock/books/multithread/book/Synchroniz, 
2: dup 
3: monitorenter  ”// monitorenter: 监视 器 进入 ， 获 取 锁 
4: monitorexit // monitorexit: 监视 器 退出 ， 释 放 锁 
5: invokestatic #16 // Method m:()V 
8: return 


public static synchronized void m(); 

// 方法 修饰 符 ， 表示 : ”public static synchronized 

flags: ACC_PUBLIC, ACC_STATIC, ACC_SYNCHRONIZED 
Code: 





stack=0, locals=0, args_size=0 
0: return 








上 面 class 信 息 中 ， 对 于 同步 块 的 实现 使 用 了 monitorenter 和 
monitorexit 指 令 ， 而 同步 方法 则 是 依靠 方法 修饰 符 上 的 


ACC_SYNCHRONIZED 来 完成 的 。 无 论 采 用 哪 种 方式 ， 其 本 质 是 对 一 
个 对 象 的 监视 器 (monitor) 进行 获取 ， 而 这 个 获取 过 程 是 排他 的 ， 也 束 
是 同一 时 刻 只 能 有 一 个 线程 获取 到 由 synchronized 所 保护 对 象 的 监视 

ee 


任意 一 个 对 象 都 拥有 自己 的 监视 器 ， 当 这 个 对 象 由 同步 块 或 者 这 个 
对 象 的 同步 方法 调用 时 ， 执 行 方法 的 线程 必须 先 获 取 到 该 对 象 的 监视 器 
才能 进入 同步 块 或 者 同步 方法 ， 而 没有 获取 到 监视 器 〈 执 行 该 方法 ) 的 
线程 将 会 被 阻塞 在 同步 块 和 同步 方法 的 入 口 处 ， 进 入 BLOCKED 状 态 。 





图 4-2 描 述 了 对 象 、 对 象 的 监视 匿 、 同 步 队 列 和 执行 线程 之 间 的 关 


系 。 
Monitor.Enter 监视 器 Monitor.Enter 成 功 对 象 Monitor.Exit 
Monitor Object 


Monitor.Exit 后 通知 ， 出 队列 











Monitor.Enter 失 败 





同步 队列 


SynchronizedQueue 





图 4-2 ” 对象、 监视 器 、 同 步 队 列 和 执行 线程 之 间 的 关系 


从 图 4-2 中 可 以 看 到 ， 任 意 线程 对 Object (Object 由 synchronized 保 
护 ) 的 访问 ， 首 先 要 获得 Object 的 监视 器 。 如 果 获 取 失 败 ， 线 程 进 入 同 


步 队 列 ， 线 程 状 态 变 为 BLOCKED。 当 访问 Object 的 前 驱 《〈 获 得 了 锁 的 
线程 ) 释放 了 锁 ， 则 该 释放 操作 唤醒 阻 竖 在 同步 队列 中 的 线程 ， 使 其 重 
新 答 试 对 监视 器 的 获取 。 


4.3.2 ”等 待 /通知 机 制 


一 个 线程 修改 了 一 个 对 象 的 值 ， 而 男 一 个 线程 感知 到 了 变化 ， 然 后 
进行 相应 的 操作 ， 整 个 过 程 开 始 于 一 个 线程 ， 而 最 终 执 行 义 是 男 一 个 线 
程 。 前 者 是 生产 者 ， 后 者 就 是 消费 者 ， 这 种 模式 隔离 了 “做 什 
么 ”(what) 和 “怎么 做 ”(How) ， 在 功能 层面 上 实现 了 解 竹 ， 体 系 结 
构 上 具备 了 良好 的 伸缩 性 ， 但 是 在 Java 语 言 中 如 何 实 现 类 似 的 功能 呢 ? 








简单 的 办 法 是 让 消费 者 线程 不 断 地 循环 检查 变量 是 否 符合 预期 ， 如 
下 面 代码 所 示 ， 在 while 循 环 中 设置 不 满足 的 条 件 ， 如 果 条 件 满足 则 退 
出 while 循 环 ， 从 而 完成 消费 者 的 工作 。 





while (value != desire) { 
Thread. sleep(1000); 


} 
doSsomething(); 





上 面 这 段 伪 代码 在 条 件 不 满足 时 就 睡眠 一 段 时 间 ， 这 样 做 的 目的 是 
防止 过 快 的 “无 效 ” 尝 试 ， 这 种 方式 看 似 能 够 解 实 现 所 需 的 功能 ， 但 是 却 
存在 如 下 问题 。 





1) 难以 确保 及 时 性 。 在 睡眠 时 ， 基 本 不 消耗 处 理 露 资源， 但 是 如 
果 睡 得 过 入， 就 不 能 及 时 发 现 条 件 已 经 变化 ， 也 就 是 及 时 性 难以 保证 。 





2) 难以 降低 开销 。 如 果 降 低 睡 眠 的 时 间 ， 比 如 休眠 1 军 秒 ， 这 样 消 


费 者 能 更 加 迅速 地 发 现 条 件 变 化 ， 但 是 却 可 能 消耗 更 多 的 处 理 器 资源 ， 
造成 了 无 端的 浪费 。 


以 上 两 个 问题 ， 看 似 矛 盾 难 以 调和 ， 但 是 Java 通 过 内 置 的 等 竺 /通知 
机 制 能 够 很 好 地 解决 这 个 予 盾 并 实现 所 需 的 功能 。 


等 待 /通知 的 相关 方法 是 任意 Java 对 象 都 具备 的 ， 因 为 这 些 方法 被 定 
义 在 所 有 对 象 的 超 类 java.lang.Object 上 ， 方 法 和 描述 如 表 4-2 所 示 。 


表 4-2 等 待 /通知 的 相关 方法 


方法 名 称 描 述 
notifyO 通知 一 个 在 对 象 上 等 待 的 线程 ， 使 其 从 wait0 方法 返回 ， 而 返回 的 前 提 是 该 线程 获取 到 了 对 象 的 锁 
notifyAll0 通知 所 有 等 待 在 该 对 象 上 的 线程 


调用 该 方法 的 线程 进入 WAITING 状态 ， 只 有 等 待 另外 线程 的 通知 或 被 中 断 才 会 返回 ， 需 要 注 
意 ， 调 用 wait0 方法 后 ， 会 释放 对 象 的 锁 
wait(long) 超时 等 待 一 段 时 间 ， 这 里 的 参数 时 间 是 毫秒 ， 也 就 是 等 待 长 达 n 毫秒 ， 如 果 没有 通知 就 超时 返回 
wait(long, inb | “对 于 超时 时 间 更 细 粒 度 的 控制 ， 可 以 达到 纳 秘 


wait() 


等 待 /通知 机 制 ， 是 指 一 个 线程 A 调用 了 对 象 0 的 wait0 方 法 进入 等 待 
状态 ， 而 另 一 个 线程 B 调 用 了 对 象 O 的 notify0 或 者 notifyAl10 方 法 ， 线 程 
A 收 到 通知 后 从 对 象 O 的 wait() 方 法 返回 ， 进 而 执行 后 续 操 作 。 上 述 两 个 
线程 通过 对 象 O 来 完成 交互 ， 而 对 象 上 的 wait0 和 notifynotifyAlO 的 关系 
就 如 同 开关 信号 一 样 ， 用 来 完成 等 待 方 和 通知 方 之 间 的 交互 工作 。 





在 代码 清单 4-11 所 示 的 例子 中 ， 创 建 了 两 个 线程 一 WaitThread 和 
NotifyThread， 前 者 检查 flag 值 是 否 为 false， 如 果 符 合 要 求 ， 进 行 后 续 操 
作 ， 否 则 在 lock 上 等 等， 后 者 在 睡眠 了 一 段 时 间 后 对 lock 进 行 通知 ， 示 





例如 下 所 示 。 


代码 清单 4-11 WaitNotify.java 





public class WaitNotify { 

static boolean flag = true; 

static Object lock = new Object(); 

public static void main(String[] args) throws Exception { 
Thread waitThread = new Thread(new Wait(), "waitThread"); 
waitThread.start(); 
TimeUnit.SECONDS. sleep(1); 
Thread notifyThread = new Thread(new Notify(), "NotifyThread"); 
notifyThread.start(); 


static class Wait implements Runnable { 
public void run() { 
// 加 锁 ， 拥 有 lock 的 Monitor 
synchronized (lock) { 
// 当 条 件 不 满足 时 ， 继 续 wait， 同 时 释放 了 lock 的 锁 
while (flag) { 
try { 
System,out.println(Thread,currentThread() + " flag is true. 
@" + new SimpleDateFormat("HH:mm:ss").format(new Date())); 
lJock.wait(); 
} catch (InterruptedException e) { 


} 


} 

// 条 件 满足 时 ， 完 成 工作 

System.out.printin(Thread,.currentThread() + " flag is false. runninc 
@" + new SimpleDateFormat("HH:mm:ss").format(new Date())); 
































} 


static class Notify implements Runnable { 
public void run() { 

// 加 锁 ， 拥 有 lock 的 Monitor 

synchronized (lock) { 
// 获取 lock 的 锁 ， 然 后 进行 通知 ， 通 知 时 不 会 释放 lock 的 锁 ， 
// 直到 当前 线程 释放 了 lock 后 ，WaitThread 才 能 从 wait 方 法 中 返回 
System.out.printin(Thread.currentThread() + " hold lock. notify @ " 
new SimpleDateFormat("HH:mm:ss").format(new Date())); 
lock.notifyAll(); 
flag = false,; 
SleepUtils. second(5); 




























































































} 

// 再 次 加 锁 

Synchronized (lock) { 
System.out.printin(Thread,.currentThread() + " hold lock again. sleer 
@" + new SimpleDateFormat("HH:mm:ss").format(new Date())); 
SleepUtils.second(5); 























输出 如 下 输出 内 容 可 能 不 同 ， 主 要 区 列 在 时 间 上 )。 





Thread[WaitThread,5,main] flag is true. wait @ 22:23:03 
Thread[NotifyThread,5,main] hold lock. notify @ 22:23:04 
Thread[NotifyThread,5,main] hold lock again. sleep @ 22:23:09 
Thread[WaitThread,s5,main] flag is false. running @ 22:23:14 





上 述 第 3 行 和 第 4 行 输出 的 顺序 可 能 会 互 换 ， 而 上 述 例子 主要 说 明了 
调用 wait()、notify0 以 及 notifyAllO 时 需要 注意 的 细节 ， 如 下 。 


1) 使 用 wait()、notify() 和 notifyAllO 时 需要 先 对 调用 对 象 加 锁 。 


2) 调用 wait0) 方 法 后 ， 线 程 状态 由 RUNNING 变 为 WAITING， 并 将 
当前 线程 放置 到 对 象 的 等 待 队列 。 


3) notify() 或 notifyAll0 方 法 调用 后 ， 等 待 线 程 依旧 不 会 从 wait() 返 
回 ， 需 要 调用 notify0) 或 notifAl10 的 线程 释放 锁 之 后 ， 等 竺 线程 才 有 机 会 
从 waitO 返 回 。 


4) notify() 方 法 将 等 待 队列 中 的 一 个 等 待 线程 从 等 待 队 列 中 移 到 同 
步 队 列 中 ， 而 notifyAl0 方 法 则 是 将 等 待 队 列 中 所 有 的 线程 全 部 移 到 同 
步 队 列 ， 被 移动 的 线程 状态 由 WAITING 变 为 BLOCKED。 


5) 从 wait( 方 法 返回 的 前 提 是 获得 了 调用 对 象 的 锁 。 


从 上 述 细节 中 可 以 看 到 ， 等 待 /通知 机 制 依托 于 同步 机 制 ， 其 目的 
就 是 确保 等 竺 线程 从 wait0 方 法 返回 时 能 够 感知 到 通知 线程 对 变量 做 出 


的 修改 。 
图 4-3 描 述 了 上 述 示例 的 过 程 。 
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图 4-3 WaitNotify.java 运 行 过 程 





在 图 4-3 中 ，WaitThread 首 先 获 取 了 对 象 的 锁 ， 然 后 调用 对 象 的 
wait(0 方 法 ， 从 而 放弃 了 锁 并 进入 了 对 象 的 等 待 队列 WaitQueue 中 ， 进 入 
等 待 状态 。 由 于 WaitThread 释 放 了 对 象 的 锁 ，NotifyThread 随 后 获取 了 
对 象 的 锁 ， 并 调用 对 象 的 notify0 方 法 ， 将 WaitThread 从 WaitQueue 移 到 
SynchronizedQueue 中 ， 此 时 WaitThread 的 状态 变 为 阻塞 状态 。 
NotifyThread 释 放 了 锁 之 后 ，WaitThread 再 次 获取 到 锁 并 从 wait() 方 法 返 


回 继续 执行 。 


4.3.3 等待 /通知 的 经 典范 式 


从 4.3.2 节 中 的 WaitNotify 示 例 中 可 以 提炼 出 等 待 /通知 的 经 典范 式 ， 
该 范式 分 为 两 部 分 ， 分 别针 对 等 待 方 (消费 者 ) 和 通知 方 〈 生 产 者 ) 。 


等 待 方 遵循 如 下 原则 。 
1) 获取 对 象 的 锁 。 


2) 如 果 条 件 不 满足 ， 那 么 调用 对 象 的 wait() 方 法 ， 被 通知 后 仍 要 检 





) 条 件 满足 则 执行 对 应 的 逻辑 。 


对 应 的 伪 代 码 如 下 。 





synchronized( 对 象 ) { 
while( 条 件 不 满足 ) { 
对 象 .wait(); 














} 
对 应 的 处 理 逻 辑 














通知 方 遵循 如 下 原则 。 


1) 获得 对 象 的 锁 。 


2) 改变 条 件 。 


3) 通知 所 有 等 竺 在 对 象 上 的 线程 。 


对 应 的 伪 代 码 如 下 。 





synchronized( 对 象 ) { 
改变 条 件 





对 象 .notifyA11( ) 
} 





4.3.4 管道 输入 /输出 流 


道 输 入 /输出 流 和 普通 的 文件 输入 /输出 流 或 者 网 络 输入 /输出 流 不 
同 之 处 在 于 ， 它 主要 用 于 线程 之 间 的 数据 传输 ， 而 传输 的 媒介 为 内 存 。 








管道 输入 /输出 流 主要 包括 了 如 下 4 种 具体 实现 : 
PipedOutputStream、PipedInputStream、PipedReader 和 PipedWriter， 前 两 
种 面 问 字 节 ， 而 后 两 种 面 癌 字符 。 


在 代码 清单 4-12 所 示 的 例子 中 ， 创 建 了 printThread， 它 用 来 接受 
main 线 程 的 输入 ， 任 何 main 线 程 的 输入 均 通 过 PipedWriter 写 入 ， 而 
printThread 在 另 一 端 通过 PipedReader 将 内 容 读 出 并 打印 。 


代码 清单 4-12 Piped.java 





public class Piped { 
public static void main(String[] args) throws Exception { 
Pipedwriter out = new PipedWwriter(); 
PipedReader in = new PipedReader(); 
// 将 输出 流 和 输入 流 进行 连接 ， 否 则 在 使 用 时 会 抛 出 IOException 
out.connect (in); 
Thread printThread = new Thread(new Print(in), "PrintThread"); 
printThread ,start(); 
int receive = 0; 
try { 
while ((receive = System,in,read()) != -1) { 
out ,write(receive ) ， 
































} 
} finally { 
out.close( ); 


static class Print implements Runnable { 
private PipedReader in; 
public Print(PipedReader in) { 
this.in = in; 


} 
public void run() { 
int receive = 0; 
try { 
while ((receive = in.read()) != -1) { 
System,.out.print((char) receive); 


} 
} catch (IOException ex) { 
} 





运行 该 示例 ， 输 入 一 组 字符 串 ， 可 以 看 到 被 printThread 进 行 了 原样 





Repeat my words. 
Repeat my words. 





对 于 Piped 类 型 的 流 ， 必 须 先 要 进行 绑 定 ， 也 就 是 调用 connect() 方 
法 ， 如 果 没 有 将 输入 /输出 流 绑 定 起 来 ， 对 于 该 流 的 访问 将 会 抛 出 异 


NE 
串 。 


4.3.5 Thread.join0O 的 使 用 


如 果 一 个 线程 A 执 行 了 thread.join0 语 句 ， 其 含义 是 : 当前 线程 A 等 
竺 thread 线程 终止 之 后 才 从 thread.join0 返 回 。 线 程 Thread 除 了 提供 join0) 
方法 之 外 ， 还 提供 了 joindong millis) 和 join(long millis,int nanos) 两 个 具备 
超时 特性 的 方法 。 这 两 个 超时 方法 表示 ， 如 采 线 程 thread 在 给 定 的 超时 
时 间 里 没有 终止 ， 那 么 将 会 从 该 超时 方法 中 返回 。 





在 代码 清单 4-13 所 示 的 例子 中 ， 创 建 了 10 个 线程 ， 编 号 0~9， 每 个 
线程 调用 前 一 个 线程 的 join0 方 法 ， 也 就 是 线程 0 结束 了， 线程 1 才能 从 
join0 方 法 中 人 返回， 而 线程 0 需要 等 待 main 线 程 结束 。 





代码 清单 4-13 Join.java 





public class Join { 
public static void main(String[] args) throws Exception { 

Thread previous = Thread.currentThread(); 

for (int i = 0; i < 10; i++) { 
// 每 个 线程 拥有 前 一 个 线程 的 引用 ， 需 要 等 待 前 一 个 线程 终止 ， 才 能 从 等 待 中 返回 
Thread thread = new Thread(new Domino(previous), String.valueof(i)); 
thread. start(); 
previous = thread; 












































} 
TimeUnit .SECONDS. sleep(5); 
System.out.printilin(Thread.currentThread().getName() + " terminate."); 


static class Domino implements Runnable { 
private Thread thread; 
public Domino(Thread thread) { 
this.thread = thread; 


public void run() { 
try { 
thread.join( ); 
} catch (InterruptedException e) { 


System,out .println(Thread,currentThread() .getName() + " terminate."); 





输出 如 下 。 





main terminate . 
9 terminate . 
1 terminate. 
2 terminate. 
3 terminate. 
4 terminate. 
5 terminate. 
6 terminate. 
7 terminate. 
8 terminate. 
9 terminate. 





从 上 述 输出 可 以 看 到 ， 每 个 线程 终止 的 前 提 是 前 驱 线 程 的 终止 ， 
个 线程 等 待 前 驱 线 程 终止 后 ， 才 从 join() 方 法 返回 ， 这 里 涉及 了 等 待 / 通 
知 机 制 〈“ 等 竺 前驱 线程 结束 ， 接 收 前 驱 线 程 结束 通知 ) 。 


代码 清单 4-14 是 JDK 中 Thread.join0 方 法 的 源码 (进行 了 部 分 调 
整 ) 。 


代码 清单 4-14 Thread.java 





// 加 锁 当 前 线程 对 象 
public final synchronized void join() throws InterruptedException { 
// 条 件 不 满足 ， 继 续 等 待 
while (isAlive()) { 
wait(0); 




















} 
// 条 件 符合 ， 方 法 返 下 











当 线 程 终止 时 ， 会 调用 线程 目 身 的 notifyA10 方 法 ， 会 通知 所 有 等 


符 在 该 线程 对 象 上 的 线程 。 可 以 看 到 join(0) 方 法 的 多 辑 结构 与 4.3.3 节 中 
描述 的 等 待 /通知 经 典范 式 一 致 ， 即 加 锁 、 循 环 和 处 理 罗 辑 3 个 步骤 。 


4.3.6 ThreadLocal 的 使 用 


ThreadLocal， 即 线程 变量 ， 是 一 个 以 ThreadLocal 对 象 为 键 、 任 意 
对 象 为 值 的 存储 结构 。 这 个 结构 被 附带 在 线程 上 ， 也 就 是 说 一 个 线程 可 
以 根据 一 个 ThreadLocal 对 象 查询 到 绑 定 在 这 个 线程 上 的 一 个 值 。 








可 以 通过 set(T) 方 法 来 设置 一 个 值 ， 在 当前 线程 下 再 通过 get() 方 法 
获取 到 原先 设置 的 值 。 


在 代码 清单 4-15 所 示 的 例子 中 ， 构 建 了 一 个 常用 的 Profiler 类 ， 它 具 
有 begin0 和 end0 两 个 方法 ， 而 end() 方 法 返回 从 begin() 方 法 调用 开始 到 
end() 方 法 被 调用 时 的 时 间 差 ， 单 位 是 毫秒 。 


代码 清单 4-15 Profiler.java 





public class Profiler { 
// 第 一 次 get ( ) 方 法 调用 时 会 进行 初始 化 (如 果 set 方 法 没有 调用 ) ， 每 个 线程 会 调用 一 次 
private static final ThreadLocal<Long> TIME_ THREADLOCAL = new ThreadLocal<Long>! 
protected Long initialValue() { 
return System.currentTimeMillis(); 







































































}; 
public static final void begin() { 
TIME_THREADLOCAL .set (System.currentTimeMillis()); 


public static final long end() { 
return System.currentTimeMillis() - TIME_ THREADLOCAL .get(); 


public static void main(String[] args) throws Exception { 
Profiler.begin(); 
TimeUnit.SECONDS. sleep(1); 
System.out.println("Cost: " + Profiler.end() + " mills"); 


和 输出 结果 如 下 所 示 。 


Cost: 1001 mills 


Profiler 可 以 被 复 用 在 方法 调用 耗 时 统计 的 功能 上 ， 在 方法 的 入 口 前 
执行 begin() 方 法 ， 在 方法 调用 后 执行 end0 方 法 ， 好 处 是 两 个 方法 的 调用 
不 用 在 一 个 方法 或 者 类 中 ， 比 如 在 AOP〔 面 向 方面 编程 》 中 ， 可 以 在 方 
法 调用 前 的 切入 点 执行 begin0 方 法 ， 而 在 方法 调用 后 的 切入 点 执行 end() 
方法 ， 这 样 依旧 可 以 获得 方法 的 执行 耗 时 。 








4.4 线程 应 用 实例 


4.4.1 等 竺 超时 模式 


开发 人 员 经 常会 过 到 这 样 的 方法 调用 场景 调用 一 个 方法 时 等 待 一 
段 时 间 (一 般 来 说 是 给 定 一 个 时 间 段 〉， 如 果 该 方法 能 够 在 给 定 的 时 间 
段 之 内 得 到 结果 ， 那 么 将 结果 立刻 返回 ， 反 之 ， 超 时 返回 默认 结果 。 

前 面 的 草 贡 介绍 了 等 竺 /通知 的 经 典范 式 ， 即 加 锁 、 条 件 循环 和 处 


理 逻 辑 3 个 步 又， 而 这 种 范式 无 法 做 到 超时 等 待 。 而 超时 等 待 的 加 入 ， 
再 要 对 经 典范 式 做 出 非常 小 的 改动 ， 改 动 内 容 如 下 所 未。 





假设 超时 时 间 段 是 T， 那 么 可 以 推断 出 在 当前 时 间 now+T 之 后 就 会 
超时 。 


定义 如 下 变量 。 
. 等 待 持 续 时 间 : REMAINING=T。 
` 超时 时 间 : FUTURE=now+ 了 T。 


这 时 仅 需要 wait(REMAINING) 即 可 ， 在 wait(REMAINING) 返 回 之 
后 会 将 执行 ， REMAINING=FUTURE-now。 如 果 REMAINING 小 于 等 于 


表示 已 经 超时 ， 直 接 退 出 ， 人 否则 将 继续 执行 wait(REMAINING)。 


上 述 描述 等 竺 超时 模式 的 伪 代 码 如 下 。 





// 对 当前 对 象 加 锁 
public synchronized Object get(long mills) throws InterruptedEXxception { 
long future = System.currentTimeMillis() + mills,; 
lJong remaining = mills,; 
// 当 超 时 大 于 9 并 且 result 返 回 值 不 满足 要 求 
while ((result == null) && remaining > 0) { 
wait(remaining); 
remaining = future - System.currentTimeMillis(); 























return result,; 








可 以 看 出 ， 等 待 超时 模式 就 是 在 等 竺 /通知 范式 基础 上 增加 了 超时 
控制 ， 这 使 得 该 模式 相 比 原 有 范式 更 具有 灵活 性 ， 因 为 即使 方法 执行 时 
司 过 长 ， 也 不 会 “永久 ?阻塞 调用 者 ， 而 是 会 按照 调用 者 的 要 求 “ 按 时 ? 返 
回 。 


4.4.2 一 个 简单 的 数据 库 连接 池 示 例 





我 们 使 用 等 待 超时 模式 来 构造 一 个 简单 的 数据 库 连 接 池 ， 在 示例 中 
模拟 从 连接 池 中 获取 、 使 用 和 释放 连接 的 过 程 ， 而 客户 端 获取 连接 的 过 
程 被 设 定 为 等 待 超 时 的 模式 ， 也 就 是 在 1000 坚 秒 内 如 果 无 法 获取 到 可 用 
连接 ， 将 会 返回 给 客户 端 一 个 null。 设 定 连 接 池 的 大 小 为 10 个 ， 然 后 通 
过 调节 客户 并 的 线程 数 来 模拟 无 法 获取 连接 的 场景 。 











首先 看 一 下 连接 池 的 定义 。 它 通过 构造 函数 初始 化 连接 的 最 大 上 
限 ， 通 过 一 个 双向 队列 来 维护 连接 ， 调 用 方 需要 先 调用 
fetchConnection(long) 方 法 来 指定 在 多 少 宣 秒 内 超时 获取 连接 ， 当 连接 使 
用 完成 后 ， 需 要 调用 releaseConnection(Connection) 方 法 将 连接 放 回 线程 
池 ， 示 例如 代码 清单 4-16 所 示 。 





代码 清单 4-16 ConnectionPool.java 





public class ConnectionPool { 
private LinkedList<Connection> pool = new LinkedList<Connection>(); 
public ConnectionPool(int initialSize) { 
if (initialSize > 0) { 
for (int i = 0; i < initialSize,; i++) { 
pool.addLast (ConnectionDriver.createConnection()); 
} 


} 


public void releaseConnection(Connection connection) { 
if (connection != nul1) { 
synchronized (pool) { 
// 连接 释放 后 需要 进行 通知 ， 这 样 其 他 消费 者 能 够 感知 到 连接 池 中 已经 归还 了 一 个 连接 
pool.addLast (connection); 
pool.notifyAll( ); 






































} 
// 在 mills 内 无 法 获取 到 连接 ， 将 会 返回 null 
public Connection fetchConnection(long mills) throws InterruptedException { 
synchronized (pool) { 
// 完全 超时 
if (mills <= 0) { 
while (pool.isEmpty()) { 
pool.wait(); 
} 


return pool.removeFirst(); 
} else { 
long future = System.currentTimeMillis() + mills,; 
long remaining = mills; 
while (pool.isEmpty() && remaining > 0) { 
pool.wait(remaining); 
remaining = future - System.currentTimeMillis(); 


























} 


Connection result = null; 
if (!pool.isEmpty()) { 

result = pool.removeFirst(); 
} 


return result,; 





由 于 java.sql.Connection 是 一 个 接口 ， 最 终 的 实现 是 由 数据 库 驱 动 提 
供 方 来 实现 的 ， 考 虑 到 只 是 个 示例 ， 我 们 通过 动态 代理 构造 了 一 个 
Connection， 该 Connection 的 代理 实现 仅仅 是 在 commitO 方 法 调用 时 休眠 
100 坚 秒 ， 示 例如 代码 清单 4-17 所 示 。 


代码 清单 4-17 ConnectionDriver.java 





public class ConnectionDriver { 
static class ConnectionHandler implements InvocationHandler { 
public Object invoke(Object proxy, Method method, Object[] args) throws Thrc 
If (method.getName().equals("commit")) { 
TimeUnit .MILLISECONDS. sleep(100); 
} 


return null; 


} 


} 

// 创建 一 个 Connection 的 代理 ， 在 commit 时 休眠 109 毫 秒 

public static final Connection createConnection() { 
return (Connection) Proxy.newProxyInstance(ConnectionDriver.class.getClassLc 
new Class<>[] { Connection.class }, new ConnectionHandler()); 

















下 面 通过 一 个 示例 来 测试 简易 数据 库 连 接 池 的 工作 情况 ， 模 拟 客户 


端 ConnectionRunner 获 取 、 使 用 、 最 后 释放 连接 的 过 程 ， 当 它 使 用 时 连 
接 将 会 增加 获取 到 连接 的 数量 ， 反 之 ， 将 会 增加 未 获取 到 连接 的 数量 ， 


示例 如 代码 清单 4-18 所 示 。 


代码 清单 4-18 ConnectionPoolTest.java 





public class ConnectionPoolTest { 








static ConnectionPool pool = new ConnectionpPool(10); 
// 保证 所 有 ConnectionRunner 能 够 同时 开始 
static CountDownLatch start = New CountDownLatch(1); 





// main 线 程 将 会 等 待 所 有 ConnectionRunner 结 束 后 才能 继续 执行 
static CountDownLatch end; 
public static void main(String[] args) throws Exception { 
// 线程 数量 ， 可 以 修改 线程 数量 进行 观察 
int threadCount = 10; 
end = new CountpownLatch(threadcount ); 
int count = 20; 
AtomicInteger got = new AtomicInteger(); 
AtomicInteger notGot = new AtomicInteger(); 
for (int i = 0; i < threadCount; i++) { 





























Thread thread = new Thread(new ConnetionRunner(count, got, notGot), 


"ConnectionRunnerThread"); 

thread. start(); 
} 
start.countDown(); 
end.await(); 
System,.out.println("total invoke: "+ (threadCount * count)); 
System,.out.println("got connection: " + got); 
System,.out.println("not got connection " + notGot ) ， 


static class ConnetionRunner implements Runnable { 


int Count ， 
AtomicInteger got; 
AtomicInteger notGot 


public ConnetionRunner(int count, AtomicInteger got，AtomicInteger notGot ) 1 


this.count = Count 
this.got = got; 
this.notGot = notGot ， 


} 
public void run() { 
try { 
start.await( ); 
} catch (Exception ex) { 


} 


while (count > 0) { 
try 





{ 
4 从 线程 池 中 获取 连接 ， 如 果 1000ms 内 无 法 获取 到 ， 将 会 返回 nu11 
/ 分 别 统计 连接 获取 的 数量 got 和 未 获取 到 的 数量 notGot 
0 connection = pool.fetchCconnection(1000) 
if (connection != nul1) { 
try { 
connection.createStatement ( ) ， 
connection.commit(); 
} finally { 
pool.releaseConnection(connection); 
got.incrementAndGet( ); 




















} 
} else { 
notGot.incrementAndGet(); 


} catch (Exception ex) { 
} finally { 
count--; 


} 


end .countDown() ， 





上 述 示例 中 使 用 了 CountDownLatch 来 确保 ConnectionRunnerThread 
能 够 同时 开始 执行 ， 并 且 在 全 部 结束 之 后 ， 才 使 main 线 程 从 等 待 状态 中 
返回 。 当 前 设 定 的 场景 是 10 个 线程 同时 运行 获取 连接 池 〈10 个 连接 ) 中 
的 连接 ， 通 过 调节 线程 数量 来 观察 未 获取 到 连接 的 情况 。 线 程 数 、 忆 3 
取 次 数 、 获 取 到 的 数量 、 未 获取 到 的 数量 以 及 未 获取 到 的 比率 ， 如 表 4- 
3 所 示 (笔者 机 器 CPU: i7-3635QM， 内 存 为 8GB， 实 际 输出 可 能 与 此 表 
不 同 ) 。 











表 4-3 ”线程 数量 与 连接 获取 的 关系 





从 表 中 的 数据 统计 可 以 看 出 ， 在 资源 一 定 的 情况 下 《连接 池 中 的 10 
个 连接 ) ， 随 着 客户 端 线 程 的 逐步 增加 ， 客 户 端 出 现 超时 无 法 获取 连接 
的 比率 不 断 升 高 。 虽 然 客户 端 线程 在 这 种 超时 获取 的 模式 下 会 出 现 连 接 





无 法 获取 的 情况 ， 但 是 它 能 够 保证 客户 端 线 程 不 会 一 直 挂 在 连接 获取 的 
操作 上 ， 而 是 “按时 ”返回 ， 并 告知 客户 并 连接 获取 出 现 问 题 ， 是 系统 的 
一 种 目 我 保护 机 制 。 数 据 库 连接 池 的 设计 也 可 以 复 用 到 其 他 的 资源 获取 
的 场景 ， 针 对 昂贵 资源 (比如 数据 库 连 接 ) 的 获取 都 应 该 加 以 超时 限 
制 |。 





4.4.3 ”线程 池 技 术 及 其 示例 





对 于 服务 器 的 程序 ， 经 常 面 对 的 是 客户 端 传 入 的 短小 《执行 时 间 
短 、 工 作 内 容 较 为 单一 ) 任务 ， 需 要 服务 端 快速 处 理 并 返回 结果 。 如 末 
服务 端 每 次 接受 到 一 个 任务 ， 创 建 一 个 线程 ， 然 后 进行 执行 ， 这 在 原型 
阶段 是 个 不 错 的 选择 ， 但 是 面 对 成 干 上 万 的 任务 递交 进 服务 占 时 ， 如 果 
还 是 采用 一 个 任务 一 个 线程 的 方式 ， 那 么 将 会 创建 数 以 万 记 的 线程 ， 这 
不 是 一 个 好 的 选择 。 因 为 这 会 使 操作 系统 频繁 的 进行 线程 上 下 文 切换 ， 
无 故 增加 系统 的 负载 ， 而 线程 的 创建 和 消亡 都 是 需要 耗费 系统 资源 的 ， 
也 无 颖 浪费 了 系统 资源 。 





线程 池 技 术 能 够 很 好 地 解决 这 个 问题 ， 它 预先 创建 了 大 干 数量 的 线 
程 ， 并 且 不 能 由 用 户 直 接 对 线程 的 创建 进行 控制 ， 在 这 个 前 提 下 重复 使 
用 固定 或 较为 固定 数目 的 线程 来 完成 任务 的 执行 。 这 样 做 的 好 处 是 ， 一 
方面 ， 消 除了 频 索 创建 和 消亡 线程 的 系统 资源 开销 ， 另 一 方面 ， 面 对 过 
量 任务 的 提交 能 够 平缓 的 劣化 。 





下 和 面 先 看 一 个 简单 的 线程 池 接口 定义 ， 示 例如 代码 清单 4-19 所 示 。 


代码 清单 4-19 ThreadPool.java 





public interface ThreadPool<Job extends Runnable> { 
// 执行 一 个 Job， 这 个 Job 需 要 实现 Runnable 
void execute(Job job); 





// 关闭 线程 池 

void shutdown(); 

// 增加 工作 者 线程 

void addworkers(int num); 
// 减少 工作 者 线程 

void removeworker(int num); 
// 得 到 正在 等 待 执行 的 任务 数量 
int getJobSize(); 

















客户 端 可 以 通过 execute(Job) 方 法 将 Job 提 交 入 线程 池 执行 ， 而 客户 
端 自 身 不 用 等 待 Job 的 执行 完成 。 除 了 execute(Job) 方 法 以 外 ， 线 程 池 接 
口 提供 了 增 大 /减少 工作 者 线程 以 及 关闭 线程 池 的 方法 。 这 里 工作 者 线 
程 代表 着 一 个 重复 执行 Job 的 线程 ， 而 每 个 由 客户 端 提 交 的 Job 都 将 进入 
到 一 个 工作 队列 中 等 待 工作 者 线程 的 处 理 。 





接 下 来 是 线程 池 接 口 的 默认 实现 ， 示 例如 代码 清单 4-20 所 示 。 


代码 清单 4-20 ”DefaultThreadPool.java 





public class DefaultThreadPool<Job extends Runnable> implements ThreadPool<Job> { 
// 线程 池 最 大 限制 数 
private static final int MAX_WORKER_NUMBERS = 10; 
// 线程 池 默 认 的 数量 
private static final int DEFAULT_WORKER_NUMBERS = 5; 
// 线程 池 最 小 的 数量 





























private static final int MIN_WORKER_NUMBERS = 1; 

// 这 是 一 个 工作 列表 ， 将 会 向 里 面 插入 工作 

private final LinkedList<Job> jobs = new LinkedList<Job>(); 

// 工作 者 列表 

private final List<Worker> workers = Collections.synchronizedList(new 


ArrayList<Worker>()); 
// 工作 者 线程 的 数量 




















private int workerNum = DEFAULT_WORKER_NUMBERS ， 
// 线程 编号 生成 
private AtomicLong threadNum = new AtomicLong( ) ; 


public DefaultThreadPool() { 
Initializewokers(DEFAULT_WORKER_NUMBERS ) ， 


} 

public DefaultThreadPool(int num) { 
workerNum = num > MAX_ WORKER_ NUMBERS MAX_ WORKER_NUMBERS : num < MIN_WORKER_ 
NUMBERS MIN_WORKER_NUMBERS : num; 
initializewokers(workerNum); 


public void execute(Job job) { 
if (job != null) { 
// 添加 一 个 工作 ， 然 后 进行 通知 
synchronized (jobs) { 
jobs.addLast(job); 
jobs.notify(); 


























} 


public void shutdown() { 
for (Worker worker : workers) { 
worker .shutdown( ); 
} 


public void addworkers(int num) { 
synchronized (jobs) { 
// 限制 新 增 的 worker 数 量 不 能 超过 最 大 值 
if (num + this.workerNum > MAX_WORKER_NUMBERS) { 
num = MAX_ WORKER_NUMBERS - this .workerNum; 
} 


initializewokers(num); 
this.workerNum += num; 








} 


public void removeWorker(int num) { 
synchronized (jobs) { 
If (num >= this.workerNum) { 
throw new IllegalArgumentException("beyond workNum"); 





} 
// 按照 给 定 的 数量 停止 Worker 
int count = 0; 
while (count < num) { 
Worker worker = workers.get(count) 
if (workers.remove(worker)) { 
worker .shutdown( ); 
Count++; 
} 
} 


this.workerNum -= count,; 
3 
} 
public int getJobSize() { 
return jobs.size(); 


} 

// 初始 化 线程 工作 者 

private void initializeWokers(int num) { 

for (int i = 0; i < num; i++) { 

Worker worker = new Worker(); 
workers.add(worker); 
Thread thread = new Thread(worker, "ThreadPool-Worker-" + threadNum. 
IncrementAndGet( ) ) ， 
thread.start(); 





} 
} 
// 工作 者 ， 负 责 消费 任务 
Class Worker implements Runnable { 











// 是 否 工 作 
private volatile boolean running = true; 


public void run() { 
while (running) { 
Job job = null; 


Synchronized (jobs) { 
// 如 果 工 作者 列表 是 空 的 ， 那 么 就 wait 
while (jobs.isEmpty()) { 
try { 
jobs .wait(); 
} catch (InterruptedException ex) { 
// 感知 到 外 部 对 WorkerThread 的 中 断 操 作 ， 返 回 
Thread.currentThread().interrupt(); 
return; 

















} 


} 
// 取出 一 个 Job 
job = jobs.removeFirst(); 





} 
if (job != null) { 
try { 
job.run(); 
} catch (Exception ex) { 
// 忽略 Job 执 行 中 的 Exception 
} 





} 
} 


} 
public void shutdown() { 
running = false,; 


} 





从 线程 池 的 实现 可 以 看 到 ， 当 客户 端 调用 execute(Job) 方 法 时 ， 会 不 
斯 地 回 任 务 列表 jobs 中 添加 Job， 而 每 个 工作 者 线程 会 不 断 地 从 jobs 上 取 
出 一 个 Job 进 行 执 行 ， 当 jobs 为 空 时 ， 工 作者 线程 进入 等 待 状态 。 





添加 一 个 Job 后 ， 对 工作 队列 jobs 调 用 了 其 notify() 方 法 ， 而 不 是 
notifyAl0 方 法 ， 因 为 能 够 确定 有 工作 者 线程 被 唤醒 ， 这 时 使 用 notify() 
方法 将 会 比 notifyAll0 方 法 获得 更 小 的 开销 (避免 将 等 待 队 列 中 的 线程 
全 部 移动 到 阻塞 队列 中 ) 。 


可 以 看 到 ， 线 程 池 的 本 质 就 是 使 用 了 一 个 线程 安全 的 工作 队列 连接 
工作 者 线程 和 客户 器 线 程 ， 客 户 端 线程 将 任务 放 入 工作 队列 后 便 返 回 ， 





而 工作 者 线程 则 不 断 地 从 工作 队列 上 取出 工作 并 执行 。 当 工作 队列 为 空 
时 ， 上 所 有 的 工作 者 线程 均等 待 在 工作 队列 上 ， 当 有 客户 问 提 交 了 一 个 任 
务 之 后 会 通知 任意 一 个 工作 者 线程 ， 随 着 大 量 的 任务 被 提交 ， 更 多 的 工 
作者 线程 会 被 唤醒 。 


4.4.4 一 个 基于 线程 池 技 术 的 简单 Web 服 务 器 


目前 的 浏览 器 都 支持 多 线程 访问 ， 比 如 说 在 请 求 一 个 HTML 页面 的 
时 候 ， 页 面 中 包含 的 图 片 资源 、 样 式 资源 会 被 浏览 右 肥 起 并 发 的 获取 ， 
这 样 用 户 融 不 会 遇 到 一 直 等 到 一 个 图 片 完 全 下 载 完 成 才能 继续 得 看 文字 
内 容 的 槛 碎 情 况 。 





如 果 Web 服 务 器 是 单线 程 的 ， 多 线程 的 浏览 絮 也 没有 用 武之 地 ， 
为 服务 疹 还 是 一 个 请 求 一 个 请 求 的 顺序 处 理 。 因 此 ， 大 部 分 Web 服 务 器 
都 是 支持 并 发 访问 的 。 常 用 的 Java Web 服 务 器 ， 如 Tomcat、Jetty， 在 其 
处 理 请 求 的 过 程 中 都 使 用 到 了 线程 池 技 术 。 











下 面 通 过 使 用 前 一 节 中 的 线程 池 来 构造 一 个 简单 的 Web 服务 器 ， 这 
个 Web 服 务 器 用 来 处 理 HTTP 请 求 ， 目 前 只 能 处 理 简 单 的 文本 和 JPG 图 片 
内 容 。 这 个 Web 服 务 器 使 用 main 线 程 不 断 地 接受 客户 端 Socket 的 连接 ， 
将 连接 以 及 请 求 提 交 给 线程 池 处 理 ， 这 样 使 得 Web 服务 器 能 够 同时 处 理 
多 个 客户 端 请 求 ， 示 例如 代码 清单 4-21 所 示 。 


代码 清单 4-21 SimpleHttpServer.java 





public class SimpleHttpServer { 
// 处 理 HttpRequest 的 线程 池 
static ThreadPool<HttpRequestHandler> threadPool = new DefaultThreadPool 
<HttpRequestHandler>(1); 
// SimpleHttpServer 的 根 路 径 
static String basePath,; 





static ServerSocket serverSocket,; 
// 服务 监听 端 
static int port = 8080 
public static void setPort(int port) { 
if (port > 0) { 
SimpleHttpServer.port = port; 
} 


public static void setBasePath(String basePath) { 
If (basePath != null && new File(basePath).exists() && new File(basePath). 
isDirectory()) { 
SimpleHttpServer.basePath = basePath 
} 
} 


// 启动 SimpleHttpServer 
public static void start() throws Exception { 
serverSocket = new ServerSocket(port); 
Socket socket = null; 
while ((socket = serverSocket.accept()) != null) { 
// 接收 一 个 客户 端 Socket， 生 成 一 个 HttpRequestHandler， 放 入 线程 池 执 行 
threadPool.execute(new HttpRequestHandler(socket)); 























} 
serverSocket.close(); 
} 
static class HttpRequestHandler implements Runnable { 


private Socket socket,; 

public HttpRequestHandler(Socket socket) { 
this.socket = socket,; 

} 


@Override 
public void run() { 
String line = null; 
BufferedReader br = null; 
BufferedReader reader = null; 
Printwriter out = null; 
InputStream in = null; 
try { 
reader = new BufferedReader(new InputStreamReader(Socket ,getInputStr 
String header = reader.readLine(); 
// 由 相对 路 径 计算 出 绝对 路 径 
String filePath = basePath + header.split(" ")[1]; 
out = new PrintWwriter(socket.getOutputSstream()); 
// 如 果 请 求 资源 的 后 级 为 jpg 或 者 jco， 则 读 取 资 源 并 输出 
if (filePpath.endswith("jpg") || filePpath.endswith("ico")) { 
in = new FileInputStream(filePath); 
ByteArrayOutputStream baos = new ByteArrayOutputStream(); 
int i = 0; 
while ((i = in.read()) != -1) { 
baos .write(i); 
} 


byte[] array = baos.toByteArray!(); 
out.println("HTTP/1.1 200 OK"); 
out.println("Server: Molly"); 
out.println("Content-Type: image/jpeg"); 
out.println("Content-Length: " + array.length); 
out.println(""); 
socket.getOutputStream().write(array, 0, array.length); 
} else { 
br = new BufferedReader(new InputStreamReader (new 
FileInputStream(filePath))); 
out = new Printwriter(socket.getOutputStream()); 











out.println("HTTP/14.1 200 OK"); 

out.println("Server: Molly"); 

out.println("Content-Type: text/html; charset=UTF-8"); 

out.println(""); 

while ((line = br.readLine()) != null) { 
out.println(line),; 


out.flush(); 
} catch (Exception ex) 
out .println("HTTP/1.1 500"); 
out .printin(""); 
out.flush(); 
} finally { 
close(br, in, reader, out, socket); 


} 


} 
// 关闭 流 或 者 Socket 
private static void close(Closeable... closeables) { 
if (closeables != nul1) { 
for (Closeable closeable : closeables) { 
try { 
closeable.close( ); 
} catch (Exception ex) { 


} 





} 
} 
} 





该 Web 服 务 右 处 理 用 户 请 求 的 时 序 图 如 ， 图 44 所 示 。 





在 图 4-4 中 ，SimpleHttpServer 在 建 并 了 与 客户 端的 连接 之 后 ， 并 不 
会 处 理 客 户 问 的 请 求 ， 而 是 将 其 包装 成 HttpRequestHandler 并 交 由 线程 
池 处 理 。 在 线程 池 中 的 Worker 处 理 客 户 端 请 求 的 同时 ， 
SimpleHttpServer 能 够 继续 完成 后 续 客 户 端 连接 的 建立 ， 不 会 阻塞 后 续 
客户 病 的 请 求 。 


接 下 来 ， 通 过 一 个 测试 对 比 来 认识 线程 池 技 术 带 来 服务 器 吞吐 量 的 
提高 。 我 们 准备 了 一 个 简单 的 HIML 页面， 内 容 如 代码 清单 4-22 所 示 。 








设置 端口 和 根 路 径 


启动 线程 池 








SimpleHttpServer ThreadPool 
1 1 
1 1 
1 1 
1 1 





包装 为 HttpRequestHandller Worker 处 理 
处 理 请 求 资源 
生成 响应 内 容 


异步 返回 


输出 内 容 到 客户 端 


图 4-4 ”SimpleHttpServer 时 序 图 


代码 清单 4-22 Index.html 





<html> 
<head> 
<title> 测 试 页 面 </title> 
</head> 
<body > 
<h1> 第 一 张 图 片 </h1> 
<img src="1.jpg" /> 
<h1> 第 二 张 图 片 </h1> 
<img src="2.jpg" /> 
<h1> 第 三 张 图 片 </h1> 
<img src="3.jpg" /> 
</body> 
</html> 















































将 SimpleHttpServer 的 根 目录 设 定 到 该 HTML 页 面 所 在 目录 ， 并 启动 


SimpleHttpServer， 通 过 Apache HTTP server benchmarking tool (版 本 
2.3) 来 测试 不 同 线程 数 下 ，SimpleHttpServer 的 吞吐 量 表现 。 





测试 场景 是 5000 次 请 求 ， 分 10 个 线程 并 发 执行 ， 测 试 内 容 主要 考察 
响应 时 间 〈 越 小 越 好 ) 和 每 秒 碍 询 的 数量 〈 越 高 越 好 ) ， 测 试 结果 如 表 
4-4 所 示 〈 笔 者 机 器 CPU: i7-3635QM， 内 存 为 8GB， 实 际 输出 可 能 与 此 
表 不 同 ) 。 


表 4-4 测试 结 





线程 池 线程 数量 10 
响应 时 间 (ms) 0.163 
每 秒 查询 的 数量 61 
测试 完成 时 间 (s) 0.816 


可 以 看 到 ， 随 着 线程 池 中 线程 数量 的 增加 ，SimpleHttpServer 的 否 
吐 量 不 断 增 大 ， 啊 应 时 间 不 断 变 小 ， 线 程 池 的 作用 非常 明显 。 








但 是 ， 线 程 池 中 线程 数量 并 不 是 越 多 越 好 ， 有 具体 的 数量 需要 评 佑 每 
个 任务 的 处 理 时 间 ， 以 及 当前 计算 机 的 处 理 器 能 力 和 数量 。 使 用 的 线程 
过 少 ， 无 法 发 挥 处 理 器 的 性 能 ， 使 用 的 线程 过 多 ， 将 会 增加 系统 的 无 故 
开销 ， 起 到 相反 的 作用 。 


4.5 ”本 章 小 结 


本 章 从 介绍 多 线程 技术 带 来 的 好 处 开始 ， 讲 述 了 如 何 启动 和 终止 线 
程 以 及 线程 的 状态 ， 详 细 阐 述 了 多 线程 之 间 进 行 通信 的 基本 方式 和 等 
待 /通知 经 典范 式 。 在 线程 应 用 示例 中 ， 使 用 了 等 得 超时 、 数 据 库 连接 
池 以 及 简单 线程 池 3 个 不 同 的 示例 巩固 本 半 前 面 章 节 所 介绍 的 Java 多 线 
程 基 础 知识 。 最 后 通过 一 个 简单 的 Web 服 务 器 将 上 述 知 识 点 串联 起 来 ， 
加 深 我 们 对 这 些 知识 点 的 理解 。 








第 5 革 Java 中 的 锁 








本 章 将 介绍 Java 并 发 包 中 与 锁 相 关 的 API 和 组 件 ， 以 及 这 些 API 和 组 
件 的 使 用 方式 和 实现 细节 。 内 容 主要 围绕 两 个 方面 : 使 用 ， 通 过 示例 
演示 这 些 组 件 的 使 用 方法 以 及 详细 介绍 与 锁 相关 的 API; 实现 ， 通 过 分 
析 源 码 来 剖析 实现 细节 ， 因 为 理解 实现 的 细节 方 能 更 加 得 心 应 手 且 正确 
地 使 用 这 些 组 件 。 和 希望 通过 以 上 两 个 方面 的 讲解 使 开发 者 对 锁 的 使 用 和 
实现 两 个 层面 有 一 定 的 了 解 。 


5.1 Lock 接 口 








锁 是 用 来 控制 多 个 线程 访问 共享 资源 的 方式 ， 一 般 来 说 ， 一 个 锁 能 
够 防止 多 个 线程 同时 访问 共享 资源 (但 是 有 些 锁 可 以 允许 多 个 线程 并 发 
的 访问 共享 资源 ， 比 如 读 写 锁 ) 。 在 Lock 接 口 出 现 之 前 ，Java 程 序 是 靠 
Synchronized 关 键 字 实现 锁 功 能 的 ， 而 Java SE 5 之 后 ， 并 发 包 中 新 增 了 
Lock 接 口 〈 以 及 相关 实现 类 ) 用 来 实现 锁 功 能 ， 它 提供 了 与 
synchronized 关 键 字 类 似 的 同步 功能 ， 只 是 在 使 用 时 需要 显 式 地 获取 和 
释放 锁 。 虽 然 它 缺少 了 (通过 synchronized 块 或 者 方法 所 提供 的 ) 隐 式 
获取 释放 锁 的 便捷 性 ， 但 是 却 拥 有 了 锁 获 取 与 释放 的 可 操作 性 、 可 中 断 
的 获取 锁 以 及 超时 获取 锁 等 多 种 synchronized 关 键 字 所 不 具备 的 同步 特 
性 。 





使 用 synchronized 关 键 字 将 会 隐 式 地 获取 锁 ， 但 是 它 将 锁 的 获取 和 
释放 固化 了 ， 也 就 是 先 获取 再 释放 。 当 然 ， 这 种 方式 简化 了 同步 的 管 
理 ， 可 是 扩展 性 没有 显示 的 锁 获 取 和 释放 来 的 好 。 例 如 ， 针 对 一 个 场 
景 ， 手 把 手 进行 锁 获 取 和 释放 ， 先 获得 锁 A， 然 后 再 获取 锁 B， 当 锁 B 获 
得 后 ， 释 放 锁 A 同 时 获取 锁 C， 当 锁 C 获 得 后 ， 再 释放 B 同 时 获取 锁 D， 
以 此 类 推 。 这 种 场景 下 ，synchronized 关 键 字 就 不 那么 容易 实现 了 ， 而 
使 用 Lock 却 容易 许多 。 








Lock 的 使 用 也 很 简单 ， 代 码 清单 5-1 是 Lock 的 使 用 的 方式 。 


代码 清单 5-1 LockUseCase.java 





Lock lock = new ReentrantLock(); 
lock.1lock(); 
try { 
} finally { 
lock.unlock(); 
} 





在 finally 块 中 释放 锁 ， 目 的 是 保证 在 获取 到 锁 之 后 ， 最 终 能 够 被 释 
放 。 


不 要 将 获取 锁 的 过 程 写 在 try 块 中 ， 因 为 如 果 在 获取 锁 (上 自 定 义 锁 的 
实现 ) 时 发 生 了 寞 第 ， 寞 常 抛 出 的 同时 ， 也 会 导致 锁 无 故 释放 。 


Lock 接 口 提供 的 synchronized 关 键 字 所 不 具备 的 主要 特性 如 表 5-1 所 


外。 
表 5-1 Lock 接 口 提供 的 synchronized 关 键 字 不 具备 的 主要 特性 
尝试 非 阻塞 地 获取 锁 当前 线程 尝试 获取 锁 ， 如 果 这 一 时 刻 锁 没 有 被 其 他 线程 获取 到 ， 则 成 功 获取 并 持 有 锁 


与 synchronized 不 同 ， 获 取 到 锁 的 线程 能 够 响应 中 断 ， 当 获取 到 锁 的 线程 被 中 断 时 ， 
中 断 异 常 将 会 被 抛 出 ， 同 时 锁 会 被 释放 
超时 获取 锁 在 指定 的 截止 时 间 之 前 获取 锁 ， 如 果 截 止 时 间 到 了 仍旧 无 法 获取 锁 ， 则 返回 


能 被 中 断 地 获取 锁 


Lock 是 一 个 接口 ， 它 定义 了 锁 获 取 和 释放 的 基本 操作 ，Lock 的 API 
如 表 5-2 所 示 。 


表 5-2 Lock 的 API 


方法 名 称 描 述 

void lockO 获取 锁 ， 调 用 该 方法 当前 线程 将 会 获取 锁 ， 当 锁 获 得 后 ， 从 该 方法 返回 

void lockInterruptiblyO | 可 中 断 地 获取 锁 ， 和 lock0) 方法 的 不 同 之 处 在 于 该 方法 会 啊 应 中 断 ， 即 在 锁 的 获取 
throws InterruptedException | 中 可 以 中 断 当前 线程 

尝试 非 阻塞 的 获取 锁 ， 调 用 该 方法 后 立刻 返回 ， 如 果 能 够 获取 则 返回 tue， 否 则 返 
回 false 

超时 的 获取 锁 ， 当 前 线程 在 以 下 3 种 情况 下 会 返回 : 

D 当 前 线程 在 超时 时 间 内 获得 了 锁 

习 当 前 线程 在 超时 时 间 内 被 中 断 

3) 超 时 时 间 结 束 ， 返 回 false 
void unlock() 释放 锁 

a a 获取 等 待 通知 组 件 ， 该 组 件 和 当前 的 锁 绑 定 ， 当 前 线程 只 有 获得 了 锁 ， 才 能 调用 该 

Condition newCondition() | ， ，， . 要 en SO 
组 件 的 wait0 方法 ， 而 调用 后 ， 当 前 线程 将 释放 锁 


boolean tryLock() 


boolean tryLock(long 
time. TimeUnit unit) throws 
InterruptedException 


这 里 先 简单 介绍 一 下 Lock 接 口 的 API， 随 后 的 章节 会 详细 介绍 同步 
器 AbstractQueuedSynchronizer 以 及 常用 Lock 接 口 的 实现 ReentrantLock。 
Lock 接 口 的 实现 基本 都 是 通过 聚合 了 一 个 同步 器 的 子 类 来 完成 线程 访问 
控制 的 。 








5.2 ”队列 同步 需 


队列 同步 器 AbstractQueuedSynchronizer 〈 以 下 简称 同步 器 ) ， 是 用 
来 构建 锁 或 者 其 他 同步 组 件 的 基础 框架 ， 它 使 用 了 一 个 int 成 员 变 量 表 示 
同步 状态 ， 通 过 内 置 的 FIFO 队 列 来 完成 资源 获取 线程 的 排队 工作 ， 并 发 
包 的 作者 (Doug Lea) 期 望 它 能 够 成 为 实现 大 部 分 同步 需求 的 基础 。 





同步 器 的 主要 使 用 方式 是 继承 ， 子 类 通过 继承 同步 器 并 实现 它 的 抽 
象 方法 来 管理 同步 状态 ， 在 抽象 方法 的 实现 过 程 中 免不了 要 对 同步 状态 
进行 更 改 ， 这 时 就 需要 使 用 同步 占 提 供 的 3 个 方法 (getState()、 
setState(int newState) 和 compareAndSetState(int expect,int update)) 来 进行 
操作 ， 因 为 它们 能 够 保证 状态 的 改变 是 安全 的 。 子 类 推荐 被 定义 为 目 定 
义 同步 组 件 的 静态 内 部 类 ， 同 步 右 自身 没有 实现 任何 同步 接口 ， 它 仅仅 
是 定义 了 若干 同步 状态 获取 和 释放 的 方法 来 供 自 定义 同步 组 件 使 用 ， 同 
步 器 既 可 以 文 持 独占 式 地 获取 同步 状态 ， 也 可 以 文 持 共享 式 地 获取 同步 
状态 ， 这 样 就 可 以 方便 实现 不 同类 型 的 同步 组 件 (ReentrantLock、 


ReentrantReadWriteLock 和 CountDownLatch 等 ) 。 








同步 器 是 实现 锁 (也 可 以 是 任意 同步 组 件 ) 的 关键 ， 在 锁 的 实现 中 
聚合 同步 项， 利用 同步 器 实现 锁 的 语义 。 可 以 这 样 理解 二 者 之 间 的 天 
系 : 锁 是 面 癌 使 用 者 的 ， 它 定义 了 使 用 者 与 锁 交 互 的 接口 《比如 可 以 多 
许 两 个 线程 并 行 访问 ) ， 隐 藏 了 实现 细节 ;同步 器 面向 的 是 锁 的 实现 





者 ， 筷 简化 了 锁 的 实现 方式 ， 屏 蔽 了 同步 状态 管理 、 线 程 的 排队 、 等 街 
与 唤醒 等 底层 操作 。 锁 和 同步 器 很 好 地 隔离 了 使 用 者 和 实现 者 所 需 关 注 
的 领域 。 





5.2.1 队列 同步 句 的 接口 与 示例 





同步 需 的 设计 是 基于 模板 方法 模式 的 ， 也 就 是 说 ， 使 用 者 需要 继承 
同步 喜 并 重 写 指定 的 方法 ， 随 后 将 同步 硕 组 合 在 目 定义 同步 组 件 的 实现 
中 ， 并 调用 同步 占 提 供 的 模板 方法 ， 而 这 些 模板 方法 将 会 调用 使 用 者 重 
写 的 方法 。 








重 写 同步 喜 指 定 的 方法 时 ， 需 要 使 用 同步 器 提供 的 如 下 3 个 方法 来 
访问 或 修改 同步 状态 。 


getState0: 获取 当前 同步 状态 。 


* setState(int newState): 设置 当前 同步 状态 。 


‘> 


* compareAndSetState(int expect,int update): 使 用 CAS 设 置 当 前 状 
态 ， 该 方法 能 够 保证 状态 设置 的 原子 性 。 


同步 器 可 重 写 的 方法 与 描述 如 表 5-3 所 示 。 


表 5-3 同步 器 可 重 写 的 方法 


方法 名 称 描 述 
独占 式 获取 同步 状态 ， 实 现 该 方法 需要 查询 当前 状态 并 判断 同步 状 
态 是 否 符 合 预期 ， 然 后 再 进行 CAS 设置 同步 状态 


protected boolean tryRelease(int arg) 独占 式 释 放 同 步 状 态 ， 等 待 获取 同步 状态 的 线程 将 有 机 会 获取 同步 状态 


protected boolean tryAcquire(int arg) 


方法 名 称 


protected int tryAcquireShared(int arg) 


描 述 
共享 式 获取 同步 状态 ， 返 回 大 于 等 于 0 的 值 ， 表 示 获 取 成 功 ， 反 之 ， 


获取 失败 


protected boolean tryReleaseShared(int arg) | ”共享 式 释 放 同 步 状态 


当前 同步 器 是 否 在 独占 模式 下 被 线程 占用 
当前 线程 所 独占 


一 般 该 方法 表示 是 否 被 
protected boolean isHeldExclusively() 该 方法 表示 是 否 被 





实现 自 定义 同步 组 件 时 ， 将 会 调用 同步 右 提 供 的 模板 方法 ， 这 些 
(部 分 ) 模板 方法 与 描述 如 表 5-4 所 示 。 


表 5-4 同步 器 提供 的 模板 方法 


方法 名 称 描 述 
独占 式 获取 同步 状态 ， 如 果 当 前 线程 获取 同步 状态 成 功 ， 则 由 该 方法 返 
void acquire(int arg) 回 ， 否则 ， 将 会 进入 同步 队列 等 待 ， 该 方法 将 会 调用 重 写 的 tryAcquire(int 
arg) 方法 
与 acquire(int arg) 相同 ， 但 是 该 方法 响应 中 断 ， 当 前 线程 未 获取 到 
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同步 状态 而 进入 同步 队列 中 ， 如 果 当 前 线程 被 中 断 ， 则 该 方法 会 抛 出 


InterruptedException 并 返回 


void acquireInterruptibly(int arg) 


上 增加 了 超时 限制 ， 如 果 当 前 线程 在 超 

时 时 间 内 没有 获取 到 同步 状态 ， 那 么 将 会 返回 false， 如 果 获 取 到 了 返回 true 
共 Ee 状态 ， 如 果 当 前 线程 未 获取 到 同步 状态 ， 将 会 进入 同步 队列 
待 ， 与 独占 式 获取 的 主要 区 别 是 在 同一 时 刻 可 以 有 多 个 线程 获取 到 同步 状态 
与 acquireShared(int arg) 相同 ， 该 方法 啊 应 中 断 


boolean tryAcquireNanos(int arg. 在 acquireInterruptibly(int arg) 基础 上 


long nanos) 
void acquireShared(int arg) 


void acquireSharedInterrmuptibly(int arg) 


boolean tryAcquireSharedNanos(int ee i 
Ye \ 在 acquireSharedInterruptibly(int arg) 基础 上 增加 了 超时 限制 
arg, long nanos) 

独占 式 的 释放 同步 状态 ， 该 方法 会 在 释放 同步 状态 之 后 ， 将 同步 队列 中 第 
一 个 节点 包含 的 线程 唤醒 
共享 式 sal 步 状 态 


字 待 在 同步 队列 上 的 线程 集合 


boolean release(int arg) 


boolean releaseShared(int arg) 


Collection<Thread> getQueuedThreads0 | ”获取 


同步 器 提供 的 模板 方法 基本 上 分 为 3 类 : 独占 式 获取 与 释放 同步 状 
态 、 共 至 式 获取 与 释放 同步 状态 和 查询 同步 队列 中 的 等 竺 线程 情况 。 目 


定义 同步 组 件 将 使 用 同步 器 提供 的 模板 方法 来 实现 目 己 的 同步 语义 


只 有 掌握 了 同步 器 的 工作 原理 才能 更 加 深入 地 理解 并 友 包 中 其 他 的 
并 发 组 件 ， 所 以 下 面 通 过 一 个 独占 锁 的 示例 来 深入 了 解 一 下 同步 器 的 工 


作 原 理 。 





顾名思义 ， 独 占 锁 就 是 在 同一 时 刻 只 能 有 一 个 线程 获取 到 锁 ， 而 其 
他 获取 锁 的 线程 只 能 处 于 同步 队列 中 等 每 ， 只 有 获取 锁 的 线程 释放 了 
锁 ， 后 继 的 线程 才能 够 获取 锁 ， 如 代码 清单 5-2 所 示 。 


代码 清单 5-2 Mutex.java 





class Mutex implements Lock { 
// 静态 内 部 类 ， 自 定义 同步 器 


private static class Sync extends AbstractQueuedSynchronizer { 
































// 是 否 处 于 占用 状态 
protected boolean isHeldExclusively() { 
return getState() == 1; 


} 

// 当 状 态 为 9 的 时 候 获取 锁 

public boolean tryAcquire(int acquires) { 
if (compareAndSetState(0, 1)) { 


setExclusiveOwnerThread(Thread.currentThread( )); 


return true; 


} 


return false; 


下 

// 释放 锁 ， 将 状态 设置 为 9 

protected boolean tryRelease(int releases) { 
if (getState() == 0) throw new 
IllegalMonitorStateException( ) ， 
setExclusiveOwnerThread(null); 
setSstate(0); 
return true; 




















// 返回 一 个 Condition， 每 个 condition 都 包含 了 一 个 condition 队 列 
Condition newCondition() { return new ConditionOobject(); } 








} 
// 仅 需 要 将 操作 代理 到 Sync 上 即 可 


private final Sync Sync = new Sync(); 


public 
public 
public 
public 
public 
public 
public 





void lock() { sync.acquire(1); } 

boolean tryLock() { return sync.tryAcquire(1); } 

void unlock() { sync.release(1); } 

Condition newCondition() { return sync.newCondition(); } 

boolean isLocked() { return sync.isHeldExclusively(); } 

boolean hasQueuedThreads() { return sync.hasQueuedThreads(); } 

void lockInterruptibly() throws InterruptedException { 
sync.acquireInterruptibly(1); 


public boolean tryLock(long timeout, TimeUnit unit) throws InterruptedException 
return sync.tryAcquireNanos(1, unit.toNanos(timeout)); 
} 


} 





述 示 例 中 ， 独 占 锁 Mutex 是 一 个 自 定义 同步 组 件 ， 它 在 同一 时 刻 
只 允许 一 个 线程 占有 锁 。Mnutex 中 定义 了 一 个 静态 内 部 类 ， 该 内 部 类 继 
承 了 同步 器 并 实现 了 独占 式 获取 和 释放 同步 状态 。 在 tryAcquire(int 
acquires) 方 法 中 ， 如 果 经 过 CAS 设 置 成 功 ( 同 步 状态 设置 为 1) ， 则 代表 
获取 了 同步 状态 ， 而 在 tryRelease(int releases) 方 法 中 只 是 将 同步 状态 重 
置 为 0。 用 户 使 用 Mutex 时 并 不 会 直接 和 内 部 同步 器 的 实现 打交道 ， 而 是 
调用 Mutex 提 供 的 方法 ， 在 Mutex 的 实现 中 ， 以 获取 锁 的 lock0) 方 法 为 
例 ， 只 需要 在 方法 实现 中 调用 同步 器 的 模板 方法 acquire(int args) 即 可 ， 
当前 线程 调用 该 方法 获取 同步 状态 失败 后 会 被 加 入 到 同步 队列 中 每 待 ， 
这 样 就 大 大 降低 了 实现 一 个 可 靠 自 定义 同步 组 件 的 门槛 。 








5.2.2 ”队列 同步 右 的 实现 分 析 


接 下 来 将 从 实现 角度 分 析 同 步 器 是 如 何 完 成 线程 同步 的 ， 主 要 包 
括 : 同步 队列 、 独 占 式 同步 状态 获取 与 释放 、 共 享 式 同步 状态 获取 与 释 
放 以 及 超时 获取 同步 状态 等 同步 器 的 核心 数据 结构 与 模板 方法 。 





1. 同 步 队 列 


同步 器 依赖 内 部 的 同步 队列 《一 个 FIFO 双 向 队列 ) 来 完成 同步 状态 
的 管理 ， 当 前 线程 获取 同步 状态 失败 时 ， 同 步 器 会 将 当前 线程 以 及 等 和 
状态 等 信息 构造 成 为 一 个 节点 〈Node) 并 将 其 加 入 同步 队列 ， 同 时 会 阻 
塞 当 前 线程 ， 当 同步 状态 释放 时 ， 会 把 首 节 点 中 的 线程 唤醒 ， 使 其 再 次 
符 试 获取 同步 状态 。 


同步 队列 中 的 节点 〈Node) 用 来 保存 获取 同步 状态 失败 的 线程 引 
用 、 等 待 状态 以 及 前 驱 和 后 继 节 点 ， 节 点 的 属性 类 型 与 名 称 以 及 描述 如 
表 5-5 所 示 。 


表 5-5 节点 的 属性 类 型 与 名 称 以 及 描述 


属性 类 型 与 名 称 描 
等 待 状态 。 
包含 如 下 状态 
D CANCELLED， 值 为 1， 由 于 在 同步 队列 中 等 待 的 线程 等 待 超时 或 者 被 中 断 ， 需 要 从 同步 队 
列 中 取消 等 待 ， 节 点 进入 该 状态 将 不 会 变化 
2) SIGNAL ， 值 为 -1， 后 继 节点 的 线程 处 于 等 待 状态 ， 而 当前 节点 的 线程 如 果 释 放 了 同步 状 
int waitStatus “| 态 或 者 被 取消 ， 将 会 通知 后 继 节点 ， 使 后 继 节点 的 线程 得 以 运行 
3) CONDITION， 值 为 -2 ， 节 点 在 等 待 队列 中 ， 节 点 线程 等 待 在 Condition 上 ， 当 其 他 线程 对 
Condition 调用 了 signal0) 方法 后 ， 该 节点 将 会 从 等 待 队 列 中 转移 到 同步 队列 中 ， 加 入 到 对 同步 状 
态 的 获取 中 
D PROPAGATE， 值 为 -3， 表 示 下 一 次 共享 式 同 步 状 态 获 取 将 会 无 条 件 地 被 传播 下 去 
5) INITIAL ， 值 为 0， 初 始 状态 


Node prev 前 驱 节 点 ， 当 节点 加 入 同步 队列 时 被 设置 (尾部 添加 ) 
Node next 后 继 节 点 


等 待 队列 中 的 后 继 节点 。 如 果 当 前 节点 是 共享 的 ， 那 么 这 个 字段 将 是 一 个 SHARED 常量 ,也 
就 是 说 节点 类 型 (独占 和 共享 ) 和 等 待 队列 中 的 后 继 节点 共用 同一 个 字段 


Thread thread 获取 同步 状态 的 线程 


Node nextWaiter 





节点 是 构成 同步 队列 (等 每 队列 ， 在 5.6 市 中 将 会 介绍 〉 的 基础 ， 
同步 器 拥有 首 节 点 (head) 和 尾 节 点 〈tal) ， 没 有 成 功 获取 同步 状态 的 
线程 将 会 成 为 节点 加 入 该 队列 的 尾部 ， 同 步 队 列 的 基本 结构 如 图 5-1 所 





compareAndSetTail(Node expect, Node update) 


图 5-1 同步 队列 的 基本 结构 


在 图 5-1 中 ， 同 步 占 包含 了 两 个 节操 类 型 的 引用 ， 一 个 指 癌 头 市 


点 ， 而 男 一 个 指向 尾 节点 。 试 想 一 下 ， 当 一 个 线程 成 功 地 获取 了 同步 状 
态 〈 或 者 锁 ) ， 其 他 线程 将 无 法 获取 到 同步 状态 ， 转 而 被 构造 成 为 节点 
并 加 入 到 同步 队列 中 ， 而 这 个 加 入 队列 的 过 程 必须 要 保证 线程 安全 ， 
此 同步 器 提供 了 一 个 基于 CAS 的 设置 尾 节 点 的 方法 : 

compareAndSetTail(Node expect,Node update)， 它 需要 传递 当前 线程 “ 认 
为 ”的 尾 节 点 和 当前 节点 ， 只 有 设置 成 功 后 ， 当 前 节点 才 正 式 与 之 前 的 


尾市 点 建 并 关联 。 





司 步 器 将 节点 加 入 到 同步 队列 的 过 程 如 图 5-2 所 示 。 


可 


CAS 设 置 尾 节点 





图 5-2 ”节点 加 入 到 同步 队列 





同步 队列 遵循 FIFO， 首 节点 是 获取 同步 状态 成 功 的 节点 ， 首 布点 的 
线程 在 释放 同步 状态 时 ， 将 会 唤醒 后 继 节 点 ， 而 后 继 节 点 将 会 在 获取 同 
步 状 态 成 功 时 将 自己 设置 为 首 贡 点 ， 该 过 程 如 岁 5-3 所 示 。 








图 5-3 首 节 点 的 设置 





在 图 5-3 中 ， 设 置 首 节点 是 通过 获取 同步 状态 成 功 的 线程 来 完成 
的 ， 由 于 只 有 一 个 线程 能 够 成 功 获 取 到 同步 状态 ， 因 此 设置 头 节 点 的 方 
法 并 不 需要 使 用 CAS 来 保证 ， 它 只 需要 将 首 节 后 设置 成 为 原 首 市 点 的 后 
继 节 点 并 断 开 原 首 节点 的 next 引 用 即 可 。 


2. 独 占 式 同步 状态 获取 与 释放 


通过 调用 同步 器 的 acquire(int arg) 方 法 可 以 获取 同步 状态 ， 该 方法 对 
中 断 不 敏感 ， 也 就 是 由 于 线程 获取 同步 状态 失败 后 进入 同步 队列 中 ， 后 
续 对 线程 进行 中 断 操 作 时 ， 线 程 不 会 从 同步 队列 中 移出 ， 该 方法 代码 如 
代码 清单 5-3 所 示 。 


代码 清单 5-3 ”同步 器 的 acquire 方 法 





public final void acquire(int arg) { 
If (!tryAcquire(arg) && 
acquireQueued(addwaiter(Node.EXCLUSIVE), arg)) 
selfIinterrupt(); 








上 述 代 码 主要 完成 了 同步 状态 获取 、 节 点 构造 、 加 入 同步 队列 以 及 
在 同步 队列 中 自 旋 等 待 的 相关 工作 ， 其 主要 逻辑 是 : 首先 调用 自 定义 同 
步 器 实现 的 tryAcquire(int arg) 方 法 ， 该 方法 保证 线程 安全 的 获取 同步 状 
态 ， 如 果 同 步 状 态 获取 失败 ， 则 构造 同步 节点 〈 独 占 式 
Node.EXCLUSIVE， 同 一 时 刻 只 能 有 一 个 线程 成 功 获取 同步 状态 ) 并 通 
过 addWaiter(Node node) 方 法 将 该 节点 加 入 到 同步 队列 的 尾部 ， 最 后 调用 
acquireQueued(Node node,int arg) 方 法 ， 使 得 该 节点 以 * 死 循环 ”的 方式 获 
取 同 步 状 态 。 如 果 获 取 不 到 则 阻塞 节点 中 的 线程 ， 而 被 阻塞 线程 的 唤醒 
主要 依靠 前 驱 节 点 的 出 队 或 阻塞 线程 被 中 断 来 实现 。 





下 面 分 析 一 下 相关 工作 。 首 先是 节点 的 构造 以 及 加 入 同步 队列 ， 如 
代码 清单 5-4 所 示 。 


代码 清单 5-4 ”同步 器 的 addWaiter 和 eng 方 法 





private Node addwaiter(Node mode) { 
Node node = new Node(Thread.currentThread(), mode); 
// 快速 尝试 在 尾部 添加 
Node pred = tail; 
If (pred != nul1) { 
node.prev = pred; 
If (compareAndSetTail(pred, node)) { 
pred.next = node; 
return node; 





} 


enq(node); 
return node,; 


private Node enq(final Node node) { 
for (;;) { 
Node t = tail; 
If (t == null) { // Must initialize 
if (compareAndSetHead(new Node())) 
tail = head; 
} else { 


node.prev = 七 

if (compareAndSetTail(t, node)) { 
t.next = node,; 
return t; 


} 





上 述 代码 通过 使 用 compareAndSetTail(Node expect,Node update) 方 法 
来 确保 节点 能 够 被 线程 安全 添加 。 试 想 一 下 : 如 果 使 用 一 个 普通 的 
LinkedList 来 维护 节点 之 间 的 关系 ， 那 么 当 一 个 线程 获取 了 同步 状态 ， 
而 其 他 多 个 线程 由 于 调用 tryAcquire(int arg) 方 法 获取 同步 状态 失败 而 并 
发 地 被 添加 到 LinkedList 时 ，LinkedList 将 难以 保证 Node 的 正确 添加 ， 最 
终 的 结果 可 能 是 节点 的 数量 有 偏差 ， 而 且 顺 序 也 是 混乱 的 。 





在 enq(final Node node) 方 法 中 ， 同 步 器 通过 “ 死 循 环 ” 来 保证 节点 的 
正确 添加 ， 在 “ 死 循环 ”中 只 有 通过 CAS 将 节点 设置 成 为 尾 节点 之 后 ， 当 
前 线程 才能 从 该 方法 返回 ， 否 则 ， 当 前 线程 不 断 地 尝试 设置 。 可 以 看 
出 ，end(final Node node) 方 法 将 并 发 添加 节点 的 请 求 通过 CAS 变 得 “ 串 行 
ET 


节点 进入 同步 队列 之 后 ， 殊 进入 了 一 个 自 旋 的 过 程 ， 每 个 市 皮 ( 或 
者 说 每 个 线程 ) 都 在 自省 地 观察 ， 当 条 件 满 足 ， 获 取 到 了 同步 状态 ， 束 
可 以 从 这 个 自 旋 过 程 中 退出 ， 人 否则 依旧 留 在 这 个 目 旋 过 程 中 《并 会 阻 守 
市 反 的 线程 》， 如 代码 清单 5-5 所 示 。 








代码 清单 5-5 ”同步 器 的 acquireQueued 方 法 


nn | 


final boolean acquireQueued(final Node node, int arg) { 
boolean failed = true; 
try { 
boolean interrupted = false; 
for (;;) { 
final Node p = node,.predecessor(); 
if (p == head && tryAcquire(arg)) { 
setHead(node); 
p.next = null; // help GC 
failed = false; 
return interrupted; 


} 
if (shouldParkAfterFailedAcquire(p, node) && 
parkAndCheckInterrupt( ) ) 

Interrupted = true; 


} 
} finally { 
if (failed) 
cancelAcquire(node); 





ed Node node,int arg) 方 法 中 ， 当 前 线程 在 “ 死 循 
环 ” 中 尝试 获取 同步 状态 ， 而 只 有 前 驱 节 点 是 头 节 点 才能 够 尝试 获取 同 
步 状态 ， 这 是 为 证 涩 ， 原因 有 两 个 ， 如 下 。 





头 贡 点 是 成 功 获 取 到 同步 状态 的 节点 ， 而 头 节 点 的 线程 释放 
了 同步 状态 之 后 ， 将 会 唤醒 其 后 继 贡 点 ， 后 继 节 点 的 线程 被 唤醒 后 需要 
检查 上 自己 的 前 驱 市 把 是 人 否 是 头 节 点。 











第 二 ， 维 护 同步 队列 的 FIFO 原 则 。 该 方法 中 ， 节 点 自 旋 获 取 同 步 状 
态 的 行为 如 图 5-4 所 示 。 


Node.prev = head && tryAcquire{args} 
头 节 点 拥有 
同步 状态 





图 5-4 节点 自 旋 获取 同步 状态 


在 图 5-4 中 ， 由 于 非 首 节 反 线程 前 驱 节 点 出 队 或 者 被 中 断 而 从 等 待 
状态 返回 ， 随 后 检查 自己 的 前 驱 是 否 是 头 节 点 ， 如 条 是 则 答 试 获取 同步 
状态 。 可 以 看 到 市 点 和 节点 之 间 在 循环 检查 的 过 程 中 基本 不 相互 通信 ， 
而 是 简单 地 判断 目 己 的 前 驱 古 否 为 尖 市 态 ， 这 样 就 使 得 节点 的 释放 规则 
符合 FIFO， 并 且 也 便于 对 过 早 通 知 的 人 处理 (过 早 通 知 是 指 前 驱 市 点 不 是 
头 节点 的 线程 由 于 中 断 而 被 唤醒 ) 。 








独占 式 同 步 状 态 获 取 流 程 ， 也 束 是 acquire(int arg) 方 法 调用 流程 ， 如 
图 5-5 所 示 。 







线程 被 中 断 或 
前 驱 节 尽 被 释放 


当前 节点 设置 
头 节 点 


® 


在 图 5-5 中 ， 前 驱 节 点 为 头 节点 且 能 够 获取 同步 状态 的 判断 条 件 和 


图 5-5 独占 式 同步 状态 获取 流程 





线程 进入 等 待 状态 是 获取 同步 状态 的 自 旋 过 程 。 当 同步 状态 获取 成 功 之 
后 ， 当 前 线程 从 acquire(int arg) 方 法 返回 ， 如 果 对 于 锁 这 种 并 发 组 件 而 








言 ， 代 表 着 当前 线程 获取 了 锁 。 


当前 线程 获取 同步 状态 并 执行 了 相应 逻辑 之 后 ， 就 需要 释放 同步 状 
态 ， 使 得 后 续 节 点 能 够 继续 获取 同步 状态 。 通 过 调用 同步 器 的 releaselint 
arg) 方 法 可 以 释放 同步 状态 ， 该 方法 在 释放 了 同步 状态 之 后 ， 会 唤醒 其 
后 继 节 点 (进而 使 后 继 节 点 重新 尝试 获取 同步 状态 )。 该 方法 代码 如 代 
码 清单 5-6 所 示 。 








代码 清单 5-6 ”同步 右 的 release 方 法 





public final boolean release(int arg) { 
if (tryRelease(arg)) { 
Node h = head; 
If (h != null && h.waitStatus != 0) 
unparkSuccessor(h); 
return true; 


} 
return false; 





该 方法 执行 时 ， 会 唤醒 头 节 点 的 后 继 节点 线程 ， 
unparkSuccessor(Node node) 方 法 使 用 LockSupport《〈 在 后 面 的 章节 会 专门 
介绍 ) 来 唤醒 处 于 等 竺 状态 的 线程 。 


分 析 了 独占 式 同 步 状态 获取 和 释放 过 程 后 ， 适 当做 个 总 结 : 在 获取 
同步 状态 时 ， 同 步 右 维护 一 个 同步 队列 ， 获 取 状 态 失 败 的 线程 都 会 被 加 
入 到 队列 中 并 在 队列 中 进行 自 旋 ; 移出 队列 (或 停止 目 旋 〉 的 条 件 是 前 
驱 节 后 为 尖 市 点 且 成 功 获 取 了 同步 状态 。 在 释放 同步 状态 时 ， 同 步 嚣 调 
用 tryRelease(int arg) 方 法 释放 同步 状态 ， 然 后 唤醒 头 节 点 的 后 继 节 点 。 





3. 共 至 式 同步 状态 获取 与 释放 





共享 式 获取 与 独占 式 获 取 最 主要 的 区 别 在 于 同一 时 刻 能 否 有 多 个 线 
程 同 时 获取 到 同步 状态 。 以 文件 的 读 写 为 例 ， 如 果 一 个 程序 在 对 文件 进 
行 读 操作 ， 那 么 这 一 时 刻 对 于 该 文件 的 写 操作 均 被 阻塞 ， 而 读 操作 能 够 
同时 进行 。 写 操作 要 求 对 资源 的 独占 式 访 问 ， 而 读 操 作 可 以 是 共享 式 访 
问 ， 两 种 不 同 的 访问 模式 在 同一 时 刻 对 文件 或 资源 的 访问 情况 ， 如 图 5- 
6 所 示 。 











图 5-6 ”共享 式 与 独占 式 访问 资源 的 对 比 


在 图 5-6 中 ， 左 半 部 分 ， 共 有 至 式 访问 资源 时 ， 其 他 共有 至 式 的 访问 均 
被 允许 ， 而 独占 式 访 问 被 阻塞 ， 右 半 部 分 是 独占 陈 访问 资源 时 ， 同 一 时 





刻 其 他 访问 均 被 阻塞 。 


过 调用 同步 器 的 acquireShared(int arg) 方 法 可 以 共享 式 地 获取 同步 
状态 ， 该 方法 代码 如 代码 清单 5-7 所 示 。 


代码 清单 5-7 同步 器 的 acquireShared 和 doAcquireShared 方 法 





public final void acquireShared(int arg) { 
if (tryAcquireShared(arg) < 0) 
doAcquireShared(arg); 
} 
private void doAcquireShared(int arg) { 
final Node node = addwaiter(Node ,SHARED ) ; 
boolean failed = true; 
try { 
boolean interrupted = false; 
for (;;) 【 
final Node p = node.predecessor(); 
if (p == head) { 
int r = tryAcquireShared(arg); 
if (r >= 0) { 
setHeadAndPropagate(node, r); 
p.next = null; 
if (interrupted) 
selfIinterrupt(); 
failed = false; 
return; 


} 


} 
if (shouldPparkAfterFailedAcquire(p, node) && 
parkAndCheckInterrupt( ) ) 

interrupted = true; 


} 
} finally { 
if (failed) 
cancelAcquire(node); 





在 acquireShared(int arg) 方 法 中 ， 同 步 器 调用 tryAcquireShared(int 
arg) 方 法 尝试 获取 同步 状态 ，tryAcquireShared(int arg) 方 法 返回 值 为 int 类 
型 ， 当 返回 值 大 于 等 于 0 时 ， 表 示 能 够 获取 到 同步 状态 。 因 此 ， 在 共享 





式 获取 的 自 旋 过 程 中 ， 成 功 获取 到 同步 状态 并 退出 自 旋 的 条 件 就 是 
tryAcquireShared(int arg) 方 法 返回 值 大 于 等 于 0。 可 以 看 到 ， 在 
doAcquireShared(int arg) 方 法 的 自 旋 过 程 中 ， 如 果 当 前 节点 的 前 驱 为 头 
节点 时 ， 尝 试 获取 同步 状态 ， 如 果 返 回 值 大 于 等 于 0， 表 示 该 次 获取 同 
步 状 态 成 功 并 从 自 旋 过 程 中 退出 。 




















与 独占 式 一 样 ， 共 享 式 获取 也 需要 释放 同步 状态 ， 通 过 调用 
releaseShared(int arg) 方 法 可 以 释放 同步 状态 ， 该 方法 代码 如 代码 清单 5-8 
所 示 。 


代码 清单 5-8 同步 器 的 releaseShared 方 法 





public final boolean releaseShared(int arg) { 
if (tryReleaseShared(arg)) { 
doReleaseShared( ); 
return true; 


} 
return false; 


} 





该 方法 在 释放 同步 状态 之 后 ， 将 会 唤醒 后 续 处 于 等 竺 状态 的 市 后 。 
对 于 能 够 文 持 多 个 线程 同时 访问 的 并 发 组 件 〈 比 如 Semaphore) ， 它 和 
独占 式 主要 区 别 在 于 tryReleaseShared(int arg) 方 法 必须 确保 同步 状态 
(或 者 资源 数 ) 线程 安全 释放 ， 一 般 是 通过 循环 和 CAS 来 保证 的 ， 因 为 
释放 同步 状态 的 操作 会 同时 来 自 多 个 线程 。 


4. 独 占 式 超时 获取 同步 状态 


通过 调用 同步 器 的 doAcquireNanos(int arg,long nanosTimeout) 方 法 可 
以 超时 获取 同步 状态 ， 即 在 指定 的 时 间 段 内 获取 同步 状态 ， 如 果 获 取 到 
同步 状态 则 返回 true， 和 否则 ， 返 回 false。 访 方法 提供 了 传统 Java 同 步 操 
作 《〈《 比 如 synchronized 关 键 字 ) 所 不 具备 的 特性 。 





在 分 析 该 方法 的 实现 前 ， 先 介绍 一 下 啊 应 中 断 的 同步 状态 获取 过 
程 。 在 Java 5 之 前 ， 当 一 个 线程 获取 不 到 锁 而 被 阻塞 在 synchronized 之 外 
时 ， 对 该 线程 进行 中 断 操作 ， 此 时 该 线程 的 中 断 标 志 位 会 被 修改 ， 但 线 
程 依旧 会 阻塞 在 synchronized 上， 等 待 着 获取 锁 。 在 Java 5 中 ， 同 步 嚣 提 
供 了 acquireInterruptibly(int arg) 方 法 ， 这 个 方法 在 等 待 获取 同步 状态 
时 ， 如 果 当 前 线程 被 中 断 ， 会 立刻 返回 ， 并 抛 出 InterruptedException。 





超时 获取 同步 状态 过 程 可 以 被 视 作 啊 应 中 断 获 取 同 步 状 态 过 程 
的 “增强 版 "?，doAcquireNanos(int arg,long nanosTimeout) 方 法 在 支持 啊 应 
中 断 的 基础 上 ， 增 加 了 超时 获取 的 特性 。 针 对 超时 获取 ， 主 要 需要 计算 
出 需要 睡眠 的 时 间 间 隔 nanosTimeout， 为 了 防止 过 早 通知 ， 
nanosTimeout 计 算 公 式 为 : nanosTimeout-=now-lastTime， 其 中 now 为 当 
前 唤醒 时 间 ，lastTime 为 上 次 唤醒 时 间 ， 如 果 nanosTimeout 大 于 0 则 表示 
超时 时 间 未 到 ， 需 要 继续 睡眠 nanosTimeout 纳 秒 ， 反 之 ， 表 示 已 经 超 
时 ， 该 方法 代码 如 代码 清单 5-9 所 示 。 





代码 清单 5-9 ”同步 器 的 doAcquireNanos 方 法 





private boolean doAcquireNanos(int arg, long nanosTimeout) 
throws InterruptedException { 
long lastTime = System.nanoTime(); 
final Node node = addwaiter(Node.EXCLUSIVE); 
boolean failed = true; 
try { 
for (;;) { 
final Node p = node.predecessor(); 
if (p == head && tryAcquire(arg)) { 
setHead(node); 
p.next = null; // help GC 
failed = false; 
return true; 


if (nanosTimeout <= 0) 
return false; 
if (shouldPparkAfterFailedAcquire(p, node) 
&& nanosTimeout > spinForTimeoutThreshold) 
LockSupport.parkNanos(this, nanosTimeout); 
long now = System,nanoTime( ); 
// 计 算 时 间 ， 当 前 时 间 now 减 去 睡眠 之 前 的 时 间 lastTime 得 到 已 经 睡眠 
// 的 时 间 delta， 然 后 被 原 有 超时 时 间 nanosTimeout 减 去 ， 得 到 了 
// 还 应 该 睡眠 的 时 间 
nanosTimeout -= now - lastTime; 
JastTime = now; 
if (Thread,.interrupted()) 
throw new InterruptedException(); 
































} 
} finally { 
if (failed) 
cancelAcquire(node); 











该 方法 在 目 旋 过 程 中 ， 当 节点 的 前 驱 节 点 为 头 节 点 时 答 试 获取 同步 


状态 ， 如 果 获 取 成 功 则 从 该 方法 返回 ， 这 个 过 程 和 独占 式 同 步 获 取 的 过 
程 类 似 ， 但 是 在 同步 状态 获取 失败 的 处 理 上 有 所 不 同 。 如 果 当 前 线程 获 
取 同 步 状态 失败 ， 则 判断 是 否 超时 (nanosTimeout 小 于 等 于 0 表示 已 经 

超时 ) ， 如 果 没 有 超时 ， 重 新 计算 超时 间隔 nanosTimeout， 然 后 使 当前 
线程 等 待 nanosTimeout 纳 秒 〈 当 已 到 设置 的 超时 时 间 ， 该 线程 会 从 











LockSupport.parkNanos(Object blocker,long nanos) 方 法 返回 ) 。 


如 果 nanosTimeout 小 于 等 于 SpinForTimeoutThreshold (1000 纳 秒 ) 


时 ， 将 不 会 使 该 线程 进行 超时 等 待 ， 而 是 进入 快速 的 目 旋 过 程 。 原 因 在 
于 ， 非 常 短 的 超时 等 竺 无 法 做 到 十 分 精确 ， 如 果 这 时 再 进行 超时 等 符 ， 
相反 会 让 nanosTimeout 的 超时 从 整体 上 表现 得 反而 不 精确 。 因 此 ， 在 超 
时 非常 短 的 场景 下 ， 同 步 需 会 进入 无 条 件 的 快速 目 旋 。 





独占 式 超时 获取 同步 态 的 流程 如 图 5-7 所 示 。 


从 图 5-7 中 可 以 看 出 ， 独 占 式 超 时 获取 同步 状态 doAcquireNanos(int 
arg,long nanosTimeout) 和 独占 式 获取 同步 状态 acquire(int args) 在 流程 上 非 
党 相似 ， 其 主要 区 别 在 于 未 获取 到 同步 状态 时 的 处 理 逻 辑 。acquire(int 
args) 在 未 获取 到 同步 状态 时 ， 将 会 使 当前 线程 一 直 处 于 等 竺 状态 ， 而 
doAcquireNanos(int arg,long nanosTimeoub) 会 使 当前 线程 等 待 
nanosTimeout 纳 秒 ， 如 果 当 前 线程 在 nanosTimeout 纳 秒 内 没有 获取 到 同 


步 状态 ， 将 会 从 等 竺 逻辑 中 目 动 返回 。 


加 入 同步 
队列 尾部 


前 驱 为 头 节点 


是 RSS 大 于 0 线程 等 符 
<=0 nanosTimeout 


线程 被 通知 


重新 计算 超时 
NanosTimeout 
当前 线程 
是 否 中 斯 


当前 线程 被 中 断 


良 出 ; 拍 出 中 断 













图 5-7 独占 式 超时 获取 同步 状态 的 流程 





5. 目 定义 同步 组 件 一 一 TwinsLock 





在 前 面 的 章节 中 ， 对 同步 器 AbstractQueuedSynchronizer 进 行 了 实现 


层面 的 分 析 ， 本 市 通过 编写 一 个 自 定 义 同步 组 件 来 加 深 对 同步 占 的 理 


解 。 





设计 一 个 同步 工具 : 该 工具 在 同一 时 刻 ， 只 允许 至 多 两 个 线程 同时 
访问 ， 超 过 两 个 线程 的 访问 将 被 阻塞 ， 我 们 将 这 个 同步 工具 命名 为 


TwinsLock。 








首先 ， 确 定 访 问 模式 。TwinsLock 能 够 在 同一 时 刻 支 持 多 个 线程 的 
访问 ， 这 显然 是 共享 式 访问 ， 因 此 ， 需 要 使 用 同步 器 提供 的 
acquireShared(int args) 方 法 等 和 Shared 相 关 的 方法 ， 这 就 要 求 TwinsLock 








必须 重 写 tryAcquireShared(int args) 方 法 和 tryReleaseShared(int args) 方 
法 ， 这 样 才能 保证 同步 右 的 共享 式 同 步 状态 的 获取 与 释放 方法 得 以 执 


/一 


介 。 


其 次 ， 定 义 资源 数 。TwinsLock 在 同一 时 刻 允 许 至 多 两 个 线程 的 同 
时 访问 ， 表 明 同 步 资源 数 为 2， 这 样 可 以 设置 初始 状态 status 为 2， 当 一 
个 线程 进行 获取 ，status 减 1， 该 线程 释放 ， 则 status 加 1， 状 态 的 合法 范 
围 为 0(、1 和 2， 其 中 0 表示 当前 已 经 有 两 个 线程 获取 了 同步 资源 ， 此 时 再 
有 其 他 线程 对 同步 状态 进行 获取 ， 该 线程 只 能 被 阻塞 。 在 同步 状态 变更 
时 ， 需 要 使 用 compareAndSet(int expect,int update) 方 法 做 原子 性 保障 。 





最 后 ， 组 合 目 定义 同步 器 。 前 面 的 章节 所 到 ， 目 定义 同步 组 件 通 过 
组 合 目 定 义 同步 天 来 完成 同步 功能 ， 一 般 情 况 下 目 定 义 同 步 器 会 被 定义 


为 自 定义 同步 组 件 的 内 部 类 。 
TwinsLock《〈 部 分 ) 代码 如 代码 清单 5-10 所 示 。 


代码 清单 5-10 TwinsLock.java 





public class TwinsLock implements Lock { 
private final Sync sync = new Sync(2); 
private static final class Sync extends AbstractQueuedSynchronizer { 
Sync(int count) { 
if (count <= 0) { 
throw new IllegalArgumentException("count must large 
than zero."); 


setstate(count); 


public int tryAcquireShared(int reduceCount) { 
for (;;) 芋 
int current = getState(); 
int newCount = current - reduceCount; 
If (newCount < 0 || compareAndSetState(current， 
newCount ) ) { 
return newCount ; 


} 

} 

public boolean tryReleaseShared(int returnCount) { 

for (;;) { 
int current = getState(); 
int newCount = current + returnCount,; 
if (compareAndSetState(current, newCount)) { 

return true; 

} 

} 


} 

} 

public void lock() { 
sync.acquireShared(1); 


} 
public void unlock() { 
sync.releaseShared(1); 


} 
// 其 他 接口 方法 略 























在 上 述 示 例 中 ，TwinsLock 实 现 了 Lock 接 口 ， 提 供 了 面向 使 用 者 的 
接口 ， 使 用 者 调用 lock0) 方 法 获取 锁 ， 随 后 调用 unlock0) 方 法 释放 锁 ， 而 


同一 时 刻 只 能 有 两 个 线程 同时 获取 到 锁 。TwinsLock 同 时 包含 了 一 个 自 
定义 同步 器 Sync， 而 该 同步 器 面向 线程 访问 和 同步 状态 控制 。 以 共享 式 
获取 同步 状态 为 例 ， 同步 器 会 先 计 算出 获取 后 的 同步 状态 ， 然 后 通过 
CAS 确 保 状 态 的 正确 设置 ， 当 tryAcquireShared(int reduceCount) 方 法 返回 
值 大 于 等 于 0 时 ， 当 前 线程 才 获 取 同 步 状态 ， 对 于 上 层 的 TwinsLock 而 
言 ， 则 表示 当前 线程 获得 了 锁 。 

同步 器 作为 一 个 桥梁 ， 连 接线 程 访问 以 及 同步 状态 控制 等 底层 技术 


与 不 同 并 发 组 件 〈 比 如 Lock、CountDownLatch 等 ) 的 接口 语义 。 


下 面 编写 一 个 测试 来 验证 TwinsLock 是 否 能 按照 预期 工作 。 在 测试 
用 例 中 ， 定 义 了 工作 者 线程 Worker， 该 线程 在 执行 过 程 中 获取 锁 ， 当 获 
取 锁 之 后 使 当前 线程 睡眠 1 秒 〈 并 不 释放 锁 ，， 随 后 打印 当前 线程 名 
称 ， 节 后 再 次 睡眠 1 秒 并 释放 锁 ， 测 试用 例如 代码 清单 5-11 所 示 。 


代码 清单 5-11 TwinsLockTest.java 





public class TwinsLockTest { 
@Test 
public void test() { 
final Lock lock = new TwinsLock(); 
class Worker extends Thread { 
public void run() { 
while (true) { 
lock.1lock(); 
try { 
SleepUtils.second(1); 
System.out.printin(Thread.currentThread().getName( )); 
SleepUtils.second(1); 
} finally { 
lock.unlock( ); 
} 


// 启动 10 个 线程 

for (int i = 0; i < 10; I++) { 
Worker w = new Worker(); 
w.setDaemon(true); 
w.start(); 


} 

// 每 阳 1 秒 换行 

for (int i = 0; i < 10; i++) { 
SleepUtils.second(1); 
System,.out.printin(); 








运行 该 测试 用 例 ， 可 以 看 到 线程 名 称 成 对 输出 ， 也 就 是 在 同一 时 刻 
只 有 两 个 线程 能 够 获取 到 锁 ， 这 表明 TwinsLock 可 以 按照 预期 正确 工 
作 。 


5.3 重 入 锁 


重 入 锁 ReentrantLock， 顾 名 思 义 ， 就 是 支持 重 进 入 的 锁 ， 它 表示 该 
锁 能 够 文 持 一 个 线程 对 资源 的 重复 加 锁 。 除 此 之 外 ， 该 锁 的 还 文 持 获取 
锁 时 的 公平 和 非 公平 性 选择 。 


回忆 在 同步 器 一 节 中 的 示例 (Mutex) ， 同 时 考虑 如 下 场景 : 当 一 
个 线程 调用 Mutex 的 lock() 方 法 获取 锁 之 后 ， 如 果 再 次 调用 lock() 方 法 ， 
则 该 线程 将 会 被 自己 所 阻塞 ， 原 因 是 Mutex 在 实现 tryAcquire(int 
acquires) 方 法 时 没有 考虑 占有 锁 的 线程 再 次 获取 锁 的 场景 ， 而 在 调用 
tryAcquire(int acquires) 方 法 时 返回 了 false， 导 致 该 线程 被 阻塞 。 简 单 地 
说 ，Mnutex 是 一 个 不 文 持 重 进入 的 锁 。 而 synchronized 关 键 字 隐 式 的 文 持 
重 进入 ， 比 如 一 个 synchronized 修 饰 的 递归 方法 ， 在 方法 执行 时 ， 执 行 
线程 在 获取 了 锁 之 后 仍 能 连续 多 次 地 获得 该 锁 ， 而 不 像 Mutex 由 于 获取 
了 锁 ， 而 在 下 一 次 获取 锁 时 出 现 阻塞 自己 的 情况 。 








ReentrantLock 虽 然 没 能 像 synchronized 关 键 字 一 样 支持 隐 式 的 重 进 
入 ， 但 是 在 调用 lock0 方 法 时 ， 已 经 获取 到 锁 的 线程 ， 能 够 再 次 调用 
lock() 方 法 获取 锁 而 不 被 阻塞 。 


这 里 提 到 一 个 锁 获取 的 公平 性 问题 ， 如 果 在 绝对 时 间 上 ， 先 对 锁 进 
行 获取 的 请 求 一 定 先 被 满足 ， 那 么 这 个 锁 是 公平 的 ， 反 之 ， 是 不 公平 


的 。 公 平 的 获取 锁 ， 也 就 是 等 每 时 间 最 长 的 线程 最 优先 获取 锁 ， 也 可 以 
说 锁 获 取 是 顺序 的 。ReentrantLock 提 供 了 一 个 构造 函数 ， 能 够 控制 锁 是 


否 是 公平 的 。 





事实 上 ， 公 平 的 锁 机 制 往往 没有 非 公 平 的 效率 高 ， 但 是 ， 并 不 是 任 
何 场景 都 是 以 TPS 作 为 唯一 的 指标 ， 公 平 锁 能 够 减少 “饥饿 "发生 的 概 
率 ， 等 待 越久 的 请 求 越 是 能 够 得 到 优先 满足 。 

下 面 将 着 重 分 析 ReentrantLock 是 如 何 实现 重 进 入 和 公平 性 获取 锁 的 
特性 ， 并 通过 测试 来 验证 公平 性 获取 锁 对 性 能 的 影响 。 


1. 实 现 重 进入 


重 进入 是 指 任意 线程 在 获取 到 锁 之 后 能 够 再 次 获取 该 锁 而 不 会 极 锁 
所 阻 窒 ， 该 特性 的 实现 需要 解决 以 下 两 个 问题 。 





1) 线程 再 次 获取 锁 。 锁 需要 去 识别 获取 锁 的 线程 是 否 为 当前 占据 
锁 的 线程 ， 如 果 是 ， 则 再 次 成 功 获取 。 








2) 锁 的 最 终 释 放 。 线 程 重复 n 次 获取 了 锁 ， 随 后 在 第 n 次 释放 该 锁 
后 ， 其 他 线程 能 够 获取 到 该 锁 。 锁 的 最 终 释 放 要 求 锁 对 于 获取 进行 计数 
自 增 ， 计 数 表示 当前 锁 被 重复 获取 的 次 数 ， 而 锁 被 释放 时 ， 计 数 自 减 ， 
当 计 数 等 于 0 时 表示 锁 已 经 成 功 释放 。 














ReentrantLock 是 通过 组 合 自 定义 同步 右 来 实现 锁 的 获取 与 释放 ， 
非 公 平 性 (默认 的 ) 实现 为 例 ， 获 取 同 步 状 态 的 代码 如 代码 清单 5-12 所 


钞 。 


代码 清单 5-12 ”ReentrantLock 的 nonfairTryAcquire 方 法 





final boolean nonfairTryAcquire(int acquires) { 
final Thread current = Thread.currentThread( ) ; 
int c = getState()， 
if (c == 0) { 
If (compareAndSetState(0, acquires)) { 
setExclusiveOwnerThread(current); 
return true; 


} else if (current == getExclusiveOwnerThread()) { 
int nextc = c + acquires; 
if (nextc < 0) 
throw new Error("Maximum lock count exceeded"); 
setSstate(nextc); 
return true; 


return false; 


ww 





该 方法 增加 了 再 次 获取 同步 状态 的 处 理 逻 辑 ， 通过 判断 当前 线程 是 
人 百 为 获取 锁 的 线程 来 决定 获取 操作 是 否 成 功 ， 如 果 是 获取 锁 的 线程 再 次 
请 求 ， 则 将 同步 状态 值 进行 增加 并 返回 true， 表 示 获 取 同 步 状态 成 功 。 


成 功 获取 锁 的 线程 再 次 获取 锁 ， 只 是 增加 了 同步 状态 值 ， 这 也 就 要 
求 ReentrantLock 在 释放 同步 状态 时 减少 同步 状态 值 ， 该 方法 的 代码 如 代 
码 清单 5-13 所 示 。 


代码 清单 5-13 ”ReentrantLock 的 tryRelease 方 法 





protected final boolean tryRelease(int releases) { 


int c = getState() - releases 
if (Thread.currentThread() != getExclusiveOwnerThread()) 
throw new IllegalMonitorStateException(); 
boolean free = false; 
if (c == 0) { 
free = true; 
setExclusiveOwnerThread(null); 


} 
setstate(c); 
return free; 





如 果 该 锁 被 获取 了 n 次 ， 那 么 前 (mn-1) 次 tryRelease(int releases) 方 法 必 
须 返 回 false， 而 只 有 同步 状态 完全 释放 了 ， 才 能 返回 true。 可 以 看 到 ， 
该 方法 将 同步 状态 是 否 为 0 作为 最 终 释 放 的 条 件 ， 当 同步 状态 为 0 时 ， 将 
占有 线程 设置 为 null， 并 返回 true， 表 示 释 放 成 功 。 








2. 公 平 与 非 公平 获取 锁 的 区 列 





公平 性 与 天 是 针对 获取 锁 而 言 的 ， 如 果 一 个 锁 是 公平 的 ， 那 么 锁 的 
获取 顺序 就 应 该 符合 请 求 的 绝对 时 间 顺 序 ， 也 就 是 FIFO。 





回顾 上 一 小 节 中 介绍 的 nonfairTryAcquire(int acquires) 方 法 ， 对 于 非 
公平 锁 ， 只 要 CAS 设 置 同步 状态 成 功 ， 则 表示 当前 线程 获取 了 锁 ， 而 公 
乎 锁 则 不 同 ， 如 代码 清单 5-14 所 示 。 


代码 清单 5-14 ”ReentrantLock 的 tryAcquire 方 法 





protected final boolean tryAcquire(int acquires) { 
final Thread current = Thread.currentThread( ); 
int c = getState()， 
if (c == 0) { 
if (!hasQueuedPredecessors() && compareAndSetState(0, acquires)) { 
setExclusiveOwnerThread(current); 
return true; 


} else if (current == getExclusiveOwnerThread()) { 
int nextc = C + acquires; 
If (nextc < 0) 
throw new Error("Maximum lock count exceeded"); 
SetState(nextc ) 
return true; 


return false; 





该 方法 与 nonfairTryAcquire(int acquires) 比 较 ， 唯 一 不 同 的 位 置 为 判 
断 条 件 多 了 hasQueuedPredecessors() 方 法 ， 即 加 入 了 同步 队列 中 当前 节 
点 是 个 有 前 驱 节 点 的 判断 ， 如 果 该 方法 返回 true， 则 表示 有 线程 比 当前 
线程 更 早 地 请 求 获 取 锁 ， 因 此 需要 等 待 前 驱 线程 获取 并 释放 锁 之 后 才能 





下 面 编写 一 个 测试 来 观察 公平 和 非 公平 锁 在 获取 锁 时 的 区 别 ， 在 测 
试用 例 中 定义 了 内 部 类 ReentrantLock2， 该 类 主要 公开 了 
getQueuedThreads() 方 法 ， 该 方法 返回 正在 等 待 获取 锁 的 线程 列表 ， 由 
于 列表 是 逆序 输出 ， 为 了 方便 观察 结果 ， 将 其 进行 反 转 ， 测 试用 例 〈 部 
分 ) 如 代码 清单 5-15 所 示 。 











代码 清单 5-15 FairAndUnfairTest.java 





public class FairAndUnfairTest { 


private static Lock fairLock = new ReentrantLock2(true); 
private static Lock unfairLock = new ReentrantLock2(false); 
@Test 
public void fair() { 

testLock(fairLock); 
} 
@Test 


public void unfair() { 
testLock(unfairLock); 


private void testLock(Lock lock) { 


} 


// 启动 5 个 Job 〈 略 ) 


private static class Job extends Thread { 


private Lock lock; 
public Job(Lock lock) { 
this.lock = lock; 


} 
public void run() { 


// 连续 2 次 打印 当前 的 Thread 和 等 待 队列 中 的 Thread (上 略 ) 








} 
} 
private static class ReentrantLock2 extends ReentrantLock { 
public ReentrantLock2(boolean fair) { 
super (fair); 
} 
public Collection<Thread> getQueuedThreads() { 
List<Thread> arrayList = new ArrayList<Thread>(super. 
getQueuedThreads()); 
Collections.reverse(arrayList); 
return arrayList; 
} 
} 





志 


观察 表 5-6 所 示 的 结果 《其 


分 别 运 行 fair() 和 unfair() 两 个 测试 方法 ， 输 出 结果 如 表 5-6 所 示 。 


表 5-6 fait0 和 unfair0 两 个 测试 方法 的 输出 结果 


Fair (公平 性 锁 ) 


Lock by [4]. Waiting by [0] 

Lock by [0], Waiting by [1. 2. 3. 4] 
Lock by [1], Waiting by [2. 3. 4. 0] 
Lock by [2], Waiting by [3. 4. 0. 1] 
Lock by [3], Waiting by [4. 0, 1. 2] 
Lock by [4], Waiting by [0. 1. 2. 3] 
Lock by [0]. Waiting by [1. 2. 3] 
Lock by [1]. Waiting by [2, 3] 
Lock by [2]. Waiting by [3] 

Lock by [3]. Waiting by [] 





从 


每 次 都 是 


个 线程 连 


U 
Lock by 
Lock by 
Lock by 
Lock by 
Lock by 
Lock by 
Lock by 


Lock by [ 


Lock by 
Lock by 


从 同步 队列 中 的 第 一 个 节点 获取 到 锁 ， 


续 获 取 锁 的 情况 。 


nfair ( 非 公平 性 锁 ) 
[4], Waiting by [0. 1. 2, 3 


Uy) 
nd 


[4]. Waiting by [0. 
[0], Waiting by [1, 2. 3] 
[0 [ 
[1 [2. 
[1], Waiting by [2, 3 
[ 
[3 
[ 
[ 


ja 
iD 
193] 
bd 


站 
]. 
], Waiting by [1. 2. 3] 
]. 


Waiting by 


td 


[2]. Waiting by [3] 
2], Waiting by [3] 
[3]. Waiting by [] 





3], Waiting by [] 


中 每 个 数字 代表 一 个 线程 ) ， 公 平 性 锁 


而 非 劣 平 住 锁 由 现 J 了 = 


为 什么 会 出 现 线程 连续 获取 锁 的 情况 呢 ? 回顾 nonfairTryAcquire(int 
acquires) 方 法 ， 当 一 个 线程 请 求 锁 时 ， 只 要 获取 了 同步 状态 即 成 功 获取 
锁 。 在 这 个 前 提 下 ， 刚 释放 锁 的 线程 再 次 获取 同步 状态 的 几率 会 非常 
大 ， 使 得 其 他 线程 只 能 在 同步 队列 中 等 待 。 


非 公 平 性 锁 可 能 使 线程 饥饿?， 为 什么 它 又 被 设 定 成 默认 的 实现 
呢 ? 再 次 观察 上 表 的 结果 ， 如 果 把 每 次 不 同 线程 获取 到 锁定 义 为 1 次 切 
换 ， 公 平 性 锁 在 测试 中 进行 了 10 次 切换 ， 而 非 公 平 性 锁 只 有 5 次 切换 ， 
这 说 明 非 公平 性 锁 的 开销 更 小 。 下 面 运行 测试 用 例 〈 测 试 环 境 : ubuntu 
server 14.04 i5-34708GB， 测 试 场景 : 10 个 线程 ， 每 个 线程 获取 100000 次 
锁 ) ， 通 过 vmstat 统 计 测 试 运 行 时 系统 线程 上 下 文 切 换 的 次 数 ， 运 行 结 
果 如 表 5-7 所 示 。 








表 5-7 公平 性 和 非 公平 性 在 系统 线程 上 下 文 切 换 方面 的 对 比 


对 比 项 Fair (公平 性 锁 ) Unfair ( 非 公平 性 锁 ) 
切换 次 数 (每 秒 间隔 ) 
183 


总 共 耗 时 (单位 : 毫秒 ) Ql 


LN 
34 
> 


在 测试 中 公平 性 锁 与 非 公平 性 锁 相 比 ， 总 耗 时 是 其 94.3 倍 ， 总 切换 
次 数 是 其 133 倍 。 可 以 看 出 ， 公 平 性 锁 保 证 了 锁 的 获取 按照 FIFO 原 则 ， 


而 代价 是 进行 大 量 的 线程 切换 。 非 公平 性 锁 昌 然 可 能 造成 线程 饥饿”， 
但 极 少 的 线程 切换 ， 保 证 了 其 更 大 的 吞吐 量 。 


5.4 读 写 锁 


之 前 提 到 锁 〈 如 Mutex 和 ReentrantLock) 基本 都 是 排他 锁 ， 这 些 锁 
在 同一 时 刻 只 允许 一 个 线程 进行 访问 ， 而 读 写 锁 在 同一 时 刻 可 以 允许 多 
个 读 线程 访问 ， 但 古 在 写 线程 访问 时 ， 所 有 的 读 线程 和 其 他 写 线程 均 被 
阻 竖 。 读 写 锁 维护 了 一 对 锁 ， 一 个 读 锁 和 一 个 写 锁 ， 通 过 分 离 读 锁 和 写 
锁 ， 使 得 并 发 性 相 比 一 般 的 排他 锁 有 了 很 大 提升 。 














除了 保证 写 操作 对 读 操 作 的 可 见 性 以 及 并 发 性 的 提升 之 外 ， 该 写 锁 
能 够 简化 读 写 交互 场景 的 编程 方式 。 假 设 在 程序 中 定义 一 个 共 孚 的 用 作 
绥 存 数据 结构 ， 它 大 部 分 时 间 提 供 读 服务 〈 例 如 查询 和 搜索 ) ， 而 写 操 
作 占 有 的 时 间 很 少 ， 但 是 写 操作 完成 之 后 的 更 新 需要 对 后 续 的 读 服 务 可 


Ue 








在 没有 读 写 锁 支 持 的 《Java 5 之 前 ) 时 候 ， 如 果 需 要 完成 上 述 工作 
就 要 使 用 Java 的 等 竺 通知 机 制 ， 就 是 当 写 操作 开始 时 ， 所 有 晚 于 写 操作 
的 读 操作 均 会 进入 等 待 状态 ， 只 有 写 操作 完成 并 进行 通知 之 后 ， 所 有 等 
竺 的 读 操 作 才 能 继续 执行 〈( 写 操作 之 间 依 徘 synchronized 关 键 进行 同 
步 ) ， 这 样 做 的 目的 是 使 读 操 作 能 读 取 到 正确 的 数据 ， 不 会 出 现 脏 读 。 
改 用 读 写 锁 实 现 上 述 功能 ， 只 需要 在 读 操作 时 获取 读 锁 ， 写 操作 时 获取 
写 锁 即 可 。 当 写 锁 极 获 取 到 时 ， 后 续 〈 非 当前 写 操作 线程 ) 的 读 写 操作 
都 会 被 阻塞 ， 写 锁 释 放 之 后 ， 所 有 操作 继续 执行 ， 编 程 方式 相对 于 使 用 





等 竺 通知 机 制 的 实现 方式 而 言 ， 变 得 简单 明了 。 


一 般 情 况 下 ， 读 写 锁 的 性 能 都 会 比 排 它 锁 好 ， 因 为 大 多 数 场 景 读 是 
多 于 写 的 。 在 读 多 于 写 的 情况 下 ， 读 写 锁 能 够 提供 比 排 它 锁 更 好 的 并 发 
性 和 吞吐 量 。Java 并 发 包 提供 读 写 锁 的 实现 是 ReentrantReadWriteLock， 
它 提 供 的 特性 如 表 5-8 所 示 。 


表 5-8 ReentrantReadWitriteLock 的 特性 


特 性 说 明 
公平 性 选择 支持 非 公 平 (默认 ) 和 公平 的 锁 获 取 方 式 ， 吞 吐 量 还 是 非 公平 优 于 公平 


该 锁 支 持 重 进 入 ， 以 读 写 线程 为 例 : 读 线程 在 获取 了 读 锁 之 后 ， 能 够 再 次 获取 读 锁 。 而 写 线程 
在 获取 了 写 锁 之 后 能 够 再 次 获取 写 锁 ， 同 时 也 可 以 获取 读 锁 
锁 降级 遵循 获取 写 锁 、 获 取 读 锁 再 释放 写 锁 的 次 序 ， 写 锁 能 够 降级 成 为 读 锁 


重 进 入 


5.4.1 读 写 锁 的 接口 与 示例 


ReadWriteLock 仪 定义 了 获取 读 锁 和 写 锁 的 两 个 方法 ， 即 readLock() 
方法 和 writeLock0) 方 法 ， 而 其 实现 ReentrantReadWriteLock， 除 了 接 
口 方法 之 外 ， 还 提供 了 一 些 便于 外 界 监控 其 内 部 工作 状态 的 方法 ， 这 些 
方法 以 及 描述 如 表 5-9 所 示 。 





表 5-9 ReentrantReadWriteLock 展 示 内 部 工作 状态 的 方法 


方法 名 称 撕 述 

返回 当前 读 锁 被 获取 的 次 数 。 该 次 数 不 等 于 获取 读 锁 的 线程 数 ， 例 如 ， 仅 一 个 线程 ， 
它 连 续 获取 ( 重 进 入 ) 了 na 次 读 锁 ， 那 么 占据 读 锁 的 线程 数 是 1， 但 该 方法 返回 n 

返回 当前 线程 获取 读 锁 的 次 数 。 该 方法 在 Java 6 中 加 入 到 ReentrantReadWriteLock 
中 ， 使 用 ThreadLocal 保存 当前 线程 获取 的 次 数 ， 这 也 使 得 Java 6 的 实现 变 得 更 加 复杂 
boolean isWriteLocked() 判断 写 锁 是 否 被 获取 


int getReadLockCount() 


int getReadHoldCount() 


int getWriteHoldCount() 返回 当前 写 锁 被 获取 的 次 数 


接 下 来 ， 通 过 一 个 缓存 示例 说 明 读 写 锁 的 使 用 方式 ， 示 例 代 码 如 代 
码 清单 5-16 所 示 。 


代码 清单 5-16 Cache.java 





public class Cache { 
static Map<String, Object> map = new HashMap<String, Object>(); 
static ReentrantReadwriteLock rwl = new ReentrantReadwriteLock(); 
static Lock r = rwl.readLock(); 
static Lock w = rwl.writeLock(); 
// 获取 一 个 key 对 应 的 value 
public static final Object get(String key) { 
r.lock(); 


try { 

return map.get(key); 
} finally { 

r.unlock(); 


} 


} 

// 设置 key 对 应 的 value， 并 返回 旧 的 value 

public static final Object put(String key, Object value) { 
w.lock(); 


try { 

return map.put(key, value); 
} finally { 

w.unlock( ); 
} 


} 

// 清空 所 有 的 内 容 

public static final void clear() { 
w.lock(); 


try { 
map.clear(); 
} finally { 
w.unlock(); 
} 


















































上 述 示例 中 ，Cache 组 合 一 个 非 线 程 安全 的 HashMap 作 为 缓存 的 实 
现 ， 同 时 使 用 读 写 锁 的 读 锁 和 写 锁 来 保证 Cache 是 线程 安全 的 。 在 读 操 
作 get(String key) 方 法 中 ， 需 要 获取 读 锁 ， 这 使 得 并 发 访 问 该 方法 时 不 会 
被 阻塞 。 写 操作 put(String key,Object value) 方 法 和 clear() 方 法 ， 在 更 新 
HashMap 时 必须 提前 获取 写 锁 ， 当 获取 写 锁 后 ， 其 他 线程 对 于 读 锁 和 与 
锁 的 获取 均 和 被 阻塞 ， 而 只 有 与 锁 被 释放 之 后 ， 其 他 读 写 操作 才能 继续 。 
Cache 使 用 读 写 锁 提 升 读 操作 的 并 发 性 ， 也 保证 每 次 写 操 作对 所 有 的 读 
写 操作 的 可 见 性 ， 同 时 简化 了 编程 方式 。 











5.4.2” 读 写 锁 的 实现 分 析 


接 下 来 分 析 ReentrantReadWriteLock 的 实现 ， 主 要 包括 : 读 写 状态 
的 设计 、 写 锁 的 获取 与 释放 、 读 锁 的 获取 与 释放 以 及 锁 降 级 〈 以 下 没有 
特别 说 明 读 写 锁 均 可 认为 是 ReentrantReadWriteLock) 。 


1. 读 写 状态 的 设计 


读 写 锁 同 样 依赖 自 定义 同步 器 来 实现 同步 功能 ， 而 读 写 状态 就 是 其 
同步 器 的 同步 状态 。 回 想 ReentrantLock 中 自 定义 同步 占 的 实现 ， 同 步 状 
态 表 示 锁 被 一 个 线程 重复 获取 的 次 数 ， 而 读 写 锁 的 目 定 义 同 步 左 需要 在 
同步 状态 一 个 整 型 变量 ) 上 维护 多 个 读 线程 和 一 个 写 线 程 的 状态 ， 使 
得 该 状态 的 设计 成 为 读 写 锁 实 现 的 关键 。 








如 采 在 一 个 整 型 变量 上 维护 多 种 状态 ， 就 一 定 需 要 "“ 按 位 切割 使 
用 ”这 个 变量 ， 读 写 锁 将 变量 切 分 成 了 两 个 部 分 ， 高 16 位 表示 读 ， 低 16 


位 表示 写 ， 划 分 方式 如 图 5-8 所 示 。 





本 | 
Selo eo ole one nolo el ooolo oo 


低 16 位 一 一 一 一 一 >| 
i 
上 一 一 一 一 一 高 16 位 一 一 一 一 | 
olololololololololololololollo 
污 状 态 =2 写 状 态 =3 


图 5-8 读 写 锁 状 态 的 划分 方式 





当前 同步 状态 表示 一 个 线程 已 经 获取 了 写 锁 ， 且 重 进 入 了 两 次 ， 同 
时 也 连续 获取 了 两 次 读 锁 。 读 写 锁 是 如 何 迅 速 确定 读 和 写 各 自 的 状态 
呢 ? 答案 是 通过 位 运算 。 假 设 当 前 同步 状态 值 为 S$， 写 状态 等 于 
S&0x0000FFFF (将 高 16 位 全 部 抹 去 ) ， 读 状态 等 于 S>>>16 (无 符号 补 
0 右 移 16 位 ) 。 当 写 状态 增加 1 时 ， 等 于 $+1， 当 读 状 态 增 加 1 时 ， 等 于 
S+(1<<16)， 也 残 是 S+0x00010000。 





根据 状态 的 划分 能 得 出 一 个 推论 : S 不 等 于 0 时 ， 当 写 状态 
CS&0x0000FFFF) 等 于 0 时 ， 则 读 状 态 〈S>>>16) 大 于 0， 即 读 锁 已 被 
获取 。 


2. 写 锁 的 获取 与 释放 


写 锁 是 一 个 支持 重 进入 的 排 它 锁 。 如 果 当 前 线程 已 经 获取 了 写 锁 ， 





则 增加 写 状 态 。 如 果 当 前 线程 在 获取 写 锁 时 ， 读 锁 已 经 被 获取 《〈 读 状态 
不 为 0) 或 者 该 线程 不 是 已 经 获取 写 锁 的 线程 ， 则 当前 线程 进入 等 待 状 
态 ， 获 取 写 锁 的 代码 如 代码 清单 5-17 所 示 。 


代码 清单 5-17 ”ReentrantReadWriteLock 的 tryAcquire 方 法 





protected final boolean tryAcquire(int acquires) { 
Thread current = Thread.currentThread(); 
int c = getState()， 
int w = exclusiveCount(c); 








if (c != 0) { 
// 存在 读 锁 或 者 当前 获取 线程 不 是 已 经 获取 写 锁 的 线程 
if (w == © || current != getExclusiveOwnerThread()) 


return false; 
if (w + exclusiveCount(acquires) > MAX_COUNT) 

throw new Error("Maximum lock count exceeded"); 
SetState(c + acquires); 
return true; 


} 
If (writerShouldBlock() || !compareAndSetState(c, c + acquires)) { 
return false; 


setExclusiveOwnerThread(current); 
return true; 





该 方法 除了 重 入 条 件 〈( 当 前 线程 为 获取 了 写 锁 的 线程 ) 之 外 ， 增 加 
了 一 个 读 锁 是 否 存在 的 判断 。 如 有 果 存 在 读 锁 ， 则 写 锁 不 能 和 被 获取 ， 原 因 
在 于 : 读 写 锁 要 确保 写 锁 的 操作 对 读 锁 可 见 ， 如 果 人 允许 读 锁 在 已 被 获取 
的 情况 下 对 写 锁 的 获取 ， 那 么 正在 运行 的 其 他 读 线程 就 无 法 感知 到 当前 
写 线程 的 操作 。 因 此 ， 只 有 等 待 其 他 读 线 程 都 释放 了 读 锁 ， 写 锁 才 能 被 
当前 线程 获取 ， 而 写 锁 一 旦 被 获取 ， 则 其 他 读 写 线程 的 后 续 访 问 均 航 阻 


ER 


本。 





写 锁 的 释放 与 ReentrantLock 的 释放 过 程 基本 类 似 ， 每 次 释放 均 减 少 





写 状态 ， 当 写 状 态 为 0 时 表示 写 锁 已 被 释放 ， 从 而 等 待 的 读 写 线程 能 够 
继续 访问 读 写 锁 ， 同 时 前 次 写 线程 的 修改 对 后 续 读 写 线程 可 见 。 





3. 读 锁 的 获取 与 释放 


读 锁 是 一 个 文 持 重 进 入 的 共享 锁 ， 它 能 够 被 多 个 线程 同时 获取 ， 在 
没有 其 他 写 线程 访问 (或 者 写 状 态 为 0) 时 ， 读 锁 总 会 被 成 功 地 获取 ， 
而 所 做 的 也 只 是 (线程 安全 的 ) 增加 读 状 态 。 如 果 当 前 线程 已 经 获取 了 
读 锁 ， 则 增加 读 状 态 。 如 有 果 当 前 线程 在 获取 读 锁 时 ， 写 锁 已 被 其 他 线程 
获取 ， 则 进入 等 待 状态 。 获 取 读 锁 的 实现 从 Java 5 到 Java 6 变 得 复杂 许 
多 ， 主 要 原因 是 新 增 了 一 些 功 能 ， 例 如 getReadHoldCount() 方 法 ， 作 用 
是 返回 当前 线程 获取 读 锁 的 次 数 。 读 状态 是 所 有 线程 获取 读 锁 次 数 的 总 
和 ， 而 每 个 线程 各 自 获 取 读 锁 的 次 数 只 能 选择 保存 在 ThreadLocal 中 ， 由 
线程 自 映 维护 ， 这 使 获取 读 锁 的 实现 变 得 复杂 。 因 此 ， 这 里 将 获取 读 锁 
的 代码 做 了 删 减 ， 保 留 必 要 的 部 分 ， 如 代码 清单 5-18 所 示 。 











代码 清单 5-18 ”ReentrantReadWriteLock 的 tryAcquireShared 方 法 





protected final int tryAcquireShared(int unused) { 
for (;;) { 
int c = getState()， 
int nextc = c+ (1 << 16); 
if (nextc < c) 
throw new Error("Maximum lock count exceeded"); 


If (exclusiveCount(c) != 0 && owner != Thread.currentThread()) 
return -1; 

If (compareAndSetState(c, nextc)) 
return 1; 


在 tryAcquireShared(int unused) 方 法 中 ， 如 末 其 他 线程 已 经 获取 了 与 
锁 ， 则 当前 线程 获取 读 锁 失败 ， 进 入 等 待 状态 。 如 采 当 前 线程 获取 了 与 
锁 或 者 写 锁 未 被 获取 ， 则 当前 线程 〈 线 程 安 全 ， 依 靠 CAS 保 证 ) 增加 读 
状态 ， 成 功 获取 读 锁 。 


读 锁 的 每 次 释放 (线程 安全 的 ， 可 能 有 多 个 读 线程 同时 释放 读 锁 ) 
均 减 少 读 状 态 ， 减 少 的 值 是 (1<<16) 。 


4. 锁 降级 


锁 降 级 指 的 是 写 锁 降级 成 为 读 锁 。 如 果 当 前 线程 拥有 写 锁 ， 然 后 将 
其 释放 ， 最 后 再 获取 读 锁 ， 这 种 分 段 完成 的 过 程 不 能 称 之 为 锁 降 级 。 锁 
降级 是 指 把持 住 《当前 拥有 的 ) 写 锁 ， 再 获取 到 读 锁 ， 随 后 释放 《先前 
拥有 的 ) 写 锁 的 过 程 。 


接 下 来 看 一 个 锁 降级 的 示例 。 因 为 数据 不 常 变化 ， 所 以 多 个 线程 可 
以 并 友 地 进行 数据 处 理 ， 当 数据 变更 后 ， 如 果 当 前 线程 感知 到 数据 变 
化 ， 则 进行 数据 的 准备 工作 ， 同 时 其 他 处 理 线程 被 阻 蹇 ， 直 到 当前 线程 
完成 数据 的 准备 工作 ， 如 代码 清单 5-19 所 示 。 


代码 清单 5-19 ”processData 方 法 





public void processData() { 
readLock.1lock(); 
if (!update) { 
// 必须 先 释放 读 锁 
readLock.unlock(); 


// 锁 降级 从 写 锁 获 取 到 开 妇 
writeLock.1lock(); 
try { 


bi 








if (!update) { 
// 准备 数据 的 流程 〈 略 ) 








update = true,; 
} 
readLock. lock(); 
} finally { 
writeLock.unlock(); 


} 
// 锁 降级 完成 ， 写 锁 降级 为 读 锁 

















} 
try { 
// 使 用 数据 的 流程 〈 略 ) 
} finally { 
readLock.unlock(); 
} 











} 








上 述 示例 中 ， 当 数据 发 生变 更 后 ，update 变 量 〈 布 尔 关 型 且 volatile 
修饰 ) 被 设置 为 false， 此 时 所 有 访问 processData0) 方 法 的 线程 都 能 够 感 
知 到 变化 ， 但 只 有 一 个 线程 能 够 获取 到 写 锁 ， 其 他 线程 会 被 阻 豆 在 读 锁 
和 号 锁 的 lock0O 方 法 上 。 当 前 线程 获取 写 锁 完成 数据 准备 之 后 ， 再 获取 
读 锁 ， 随 后 释放 写 锁 ， 完 成 锁 降 级 。 


锁 降 级 中 该 锁 的 获取 是 否 必 要 呢 ? 答案 是 必要 的 。 主 要 是 为 了 保证 
数据 的 可 见 性 ， 如 果 当 前 线程 不 获取 读 锁 而 是 直接 释放 写 锁 ， 假设 此 刻 
另 一 个 线程 〈 记 作 线 程 T) 获取 了 写 锁 并 修改 了 数据 ， 那 么 当前 线程 无 
法 感知 线程 T 的 数据 更 新 。 如 果 当 前 线程 获取 读 锁 ， 即 章 循 锁 降 级 的 步 
又 ， 则 线程 T 将 会 被 阻 竖 ， 直 到 当前 线程 使 用 数据 并 释放 读 锁 之 后 ， 线 
程 T 才 能 获取 写 锁 进行 数据 更 新 。 


RentrantReadWriteLock 不 文 持 锁 升级 〈 把 持 读 锁 、 获 取 写 锁 ， 最 后 
释放 读 锁 的 过 程 ) 。 目 的 也 是 保证 数据 可 见 性 ， 如 果 读 锁 已 被 多 个 线程 





获取 ， 其 中 任意 线程 成 功 获取 了 写 锁 并 更 新 了 数据 ， 则 其 更 新 对 其 他 获 
取 到 读 锁 的 线程 是 不 可 见 的 。 


5.5 LockSupport 工 具 


回顾 5.2 节 ， 当 需要 阻塞 或 唤醒 一 个 线程 的 时 候 ， 都 会 使 用 
LockSupport 工 具 类 来 完成 相应 工作 。LockSupport 定 义 了 一 组 的 公共 静 
态 方法 ， 这 些 方 法 提供 了 最 基本 的 线程 阻 窜 和 唤醒 功能 ， 
LockSupport 也 成 为 构建 同步 组 件 的 基础 工具 。 





LockSupport 定 义 了 一 组 以 park 开 头 的 方法 用 来 阻塞 当前 线程 ， 以 及 
unpark(Thread thread) 方 法 来 唤醒 一 个 被 阻塞 的 线程 。Park 有 停车 的 意 
思 ， 假 设 线程 为 车 辆 ， 那 么 park 方 法 代表 着 停车 ， 而 unpark 方 法 则 是 指 
车 辆 启动 离开 ， 这 些 方 法 以 及 描述 如 表 5-10 所 示 。 


表 5-10 LockSuppott 提 供 的 阻塞 和 唤醒 方法 


方法 名 称 描 述 
明 塞 当前 线程 ， 如 果 调 用 unpark(Thread thread) 方法 或 者 当前 线程 被 中 断 ， 才 


VAR 从 park() 方法 返回 


> 


EC 


昌 塞 当前 线程 ， 最 长 不 超过 nanos 纳 秒 ， 返 回 条 件 在 park0 的 基础 上 增加 了 
void parkNanos(long nanos) [线程 ， 最 t 到 和 ; K 人 4 1 





超时 返回 
void parkUntil(long deadline) 钥 塞 当前 线程 ， 直 到 deadline 时 间 (从 1970 年 开始 到 deadline 时 间 的 毫秒 数 ) 
void unpark(Thread thread) 唤 根 处 于 阻塞 状态 的 线程 thread 


在 Java 6 中 ，LockSupport 增 加 了 park(Object blocker)、 
parkNanos(Object blocker,long nanos) 和 parkUntil(Object blocker,long 
deadline)3 个 方法 ， 用 于 实现 阻塞 当前 线程 的 功能 ， 其 中 参数 blocker 是 
用 来 标识 当前 线程 在 等 竺 的 对 象 〈 以 下 称 为 阻塞 对 象 ) ， 该 对 象 主要 用 





于 问题 排 得 和 系统 监控 。 


下 面 的 示例 中 ， 将 对 比 parkNanos(long nanos) 方 法 和 
parkNanos(Object blocker,long nanos) 方 法 来 展示 阻塞 对 象 blocker 的 用 
处 ， 代 码 片 段 和 线程 dqmp (部 分 〉 如 表 5-11 所 示 。 





从 表 5-11 的 线程 dump 结 果 可 以 看 出 ， 代 码 片 段 的 内 容 都 是 阻塞 当前 
线程 10 秒 ， 但 从 线程 dump 结 果 可 以 看 出 ， 有 阻塞 对 象 的 parkNanos 方 法 
能 够 传递 给 开发 人 员 更 多 的 现场 信息 。 这 是 由 于 在 Java 5 之 前 ， 当 线程 
阻塞 〈 使 用 synchronized 关 键 字 ) 在 一 个 对 象 上 时 ， 通 过 线程 dump 能 人 够 
碍 看 到 该 线程 的 阻 压 对 象 ， 方 便 问 题 定位 ， 而 Java 5 推出 的 Lock 等 并 发 
工具 时 却 遗漏 了 这 一 点 ， 致 使 在 线程 dump 时 无 法 提供 阻塞 对 象 的 信 
息 。 因 此 ， 在 Java 6 中 ，LockSupport 新 增 了 上 述 3 个 含有 阻塞 对 象 的 park 
方法 ， 用 以 蔡 代 原 有 的 park 方 法 。 





表 5-11 Blocket 在 线程 dump 中 的 作用 


对 比 项 


代码 片段 


线程 
dump 





parkNanos(long nanos) parkNanos(Object blocker, long nanos) 


LockSupport .parkNanos (TimeUnit. LockSupport.parkNanos (this, TimeUnit. 
SECONDS .toNanos (10) ) ; SECONDS .toNanos (10) ) ; 
“有 "main"” prio=5 tid=0x00007fd248805800 
Qx0O000TEfer 3000800 mid=|Iniqdq=0%1303 waitinmg On Gondit1ion 
0x1303 waiting on condition| [0x000000010d75£000] 
[Ox000000010kbb85000] java.lang.Thread.State: TIMED WAITING 
java.lang.Thread.State:| (parking) 
TIMED WAITING (parking) at sun.misc.Unsafe.park (Native Method) 
= 人 Na es — parking to wait for <0x00000007d593ec98> 
park (Native Method) (a com.murdock.books.multithread.book. 
at Javautil concurrent:|LocksupportTest) 
小 籽 台 中 六 加 罗 攻 和 下 at java.util.concurrent.locks.LockSupport. 


parkNanos (LockSupport .java:349) |parkNanos (LockSupport.java:226) 


5.6 _ Condition 接口 


任意 一 个 Java 对 象 ， 都 拥有 一 组 监视 器 方法 (定义 在 
java.lang.Object 上 ) ， 主 要 包括 wait()、wait(long timeout)、notify() 以 及 
notifyAll0 方 法 ， 这 些 方法 与 synchronized 同 步 关 键 字 配合 ， 可 以 实现 等 
待 /通知 模式 。Condition 接 口 也 提供 了 类 似 Object 的 监视 器 方法 ， 与 Lock 
配合 可 以 实现 等 竺 /通知 模式 ， 但 是 这 两 者 在 使 用 方式 以 及 功能 特性 上 
还 是 有 差别 的 。 





通过 对 比 Object 的 监视 器 方法 和 Condition 接 口 ， 可 以 更 详细 地 了 解 
Condition 的 特性 ， 对 比 项 与 结果 如 表 5-12 所 示 。 


表 5-12 ” Object 的 监视 器 方法 与 Condition 接 口 的 对 比 


对 比 项 Object Monitor Methods Condition 


调用 Lock.lock0 获取 锁 





前 曾 条 件 兴 取 对 象 的 锁 i 
脐 略 条 但 计 调用 Lock.newCondition( 获取 Condition 对 象 
ei 直接 调用 直接 调用 
调用 方式 Ste i 
如 : object.wait() 如 : condition.await() 
等 待 队列 个 数 一 个 多 个 


当前 线程 种 放 硕 于 还 等待 大 太 中 
和 前 线程 释放 锁 并 进入 等 待 状态 ， 在 
等 待 状 态 中 不 响应 中 断 


当前 线程 释放 锁 并 进入 超时 等 待 状态 支持 


当前 线程 释放 锁 并 进入 等 待 状态 到 将 i Et 
A 不 支持 支持 
来 的 某 个 时 间 
唤醒 等 待 队列 中 的 一 个 线 各 支持 


唤醒 等 待 队 列 中 的 全 部 线程 支持 妈 持 














5.6.1 ”Condition 接 口 与 示例 


Condition 定 义 了 等 待 /通知 两 种 类 型 的 方法 ， 当 前 线程 调用 这 些 方 
法 时 ， 需 要 提前 获取 到 Condition 对 象 关联 的 锁 。Condition 对 象 是 由 Lock 
对 象 〈 调 用 Lock 对 象 的 newCondition() 方 法 ) 创建 出 来 的 ， 换 名 话说， 
Condition 是 依赖 Lock 对 象 的 。 





Condition 的 使 用 方式 比较 简单 ， 需 要 注意 在 调用 方法 前 获取 锁 ， 使 
用 方式 如 代码 清单 5-20 所 示 。 


代码 清单 5-20 ConditionUseCase.java 





Lock lock = new ReentrantLock(); 
Condition condition = lock.newCondition(); 
public void conditionwait() throws InterruptedException { 
lock.1lock(); 
try { 
condition.await( ); 
} finally { 
lock.unlock( ); 
} 


public void conditionSignal() throws InterruptedException { 
lock.1lock(); 
try { 
condition.signal( ); 
} finally { 
lock.unlock( ); 
} 


} 





如 示例 所 示 ， 一 般 都 会 将 Condition 对 象 作为 成 员 变 量 。 当 调用 
await(0 方 法 后 ， 当 前 线程 会 释放 锁 并 在 此 等 待 ， 而 其 他 线程 调用 


Condition 对 象 的 signal(0) 方 法 ， 通 知 当 前 线程 后 ， 当 前 线程 才 从 await() 方 
法 返回 ， 并 且 在 返回 前 已 经 获取 了 锁 。 


Condition 定 义 的 《部 分 ) 方法 以 及 描述 如 表 5-13 所 示 。 


表 5-13 Condition 的 (部 分 ) 方法 以 及 描述 
方法 名 称 描 述 
当前 线程 进入 等 待 状态 直到 被 通知 ( signal) 或 中 断 ， 当 前 线程 将 进入 运行 状态 且 
从 await0 方法 返回 的 情况 ， 包括: 


void await() throws Interru- | ”其 他 线程 调用 该 Condition 的 signal0 或 signalAll0 方法 ， 而 当前 线程 被 选中 唤醒 





ptedException 口 其 他 线程 (调用 interrupt0 方法 ) 中 断 当 前 线程 
口 如 果 当 前 等 待 线程 从 await0 方法 返回 ， 那 么 表明 该 线程 已 经 获取 了 Condition 
对 象 所 对 应 的 锁 
( 续 ) 
方法 名 称 描 述 


void awaitUninterruptibly() | “当前 线程 进入 等 待 状态 直到 被 通知 ， 从 方法 名 称 上 可 以 看 出 该 方法 对 中 断 不 敏感 

long awaitNanos(long nanos- | ”当前 线程 进入 等 待 状态 直到 被 通知 、 中 断 或 者 超时 。 返 回 值 表示 剩余 的 时 间 ， 如 
Timeout) throws Interrupted- | 果 在 nanosTimeonut 纳 秒 之 前 被 唤醒 ， 那么 返回 值 就 是 anosTimeout- 实际 耗 时 ) 
Exception 如 果 返 回 值 是 0 或 者 负数 ， 那 么 可 以 认定 已 经 超时 了 


boolean awaitUntil(Date ed AR RE NT 
( 当前 线程 进入 等 待 状态 直到 被 通知 、 中 断 或 者 到 某 个 时 间 。 如 果 没 有 到 指定 时 间 


deadline) throws InterTu-| 、、 、 ， 人 i 8 A 
) 就 被 通知 ， 方 法 返回 true， 否 则 ， 表 示 到 了 指定 时 间 ， 方 法 返回 false 


ptedException 

唤醒 一 个 等 竺 在 Condition 上 的 线程 ， 该 线程 从 等 待 方法 返回 前 必须 获得 与 
Condition 相关 联 的 锁 

唤醒 所 有 等 待 在 Condition 上 的 线程 ， 能够 从 等 待 方法 返回 的 线程 必须 获得 与 
Condition 相关 联 的 锁 


void signal() 


void signalAll() 


获取 一 个 Condition 必 须 通 过 Lock 的 newCondition() 方 法 。 下 面 通 过 
一 个 有 界 队 列 的 示例 来 深入 了 解 Condition 的 使 用 方式 。 有 界 队列 是 一 种 
特殊 的 队列 ， 当 队列 为 空 时 ， 队 列 的 获取 操作 将 会 阻塞 获取 线程 ， 直 到 
队列 中 有 新 增 元 素 ， 当 队列 已 满 时 ， 队 列 的 插入 操作 将 会 阻塞 插入 线 
程 ， 直 到 队列 出 现 * 空 位 >， 如 代码 清单 5-21 所 示 。 


代码 清单 5-21 BoundedQueue.java 





public class BoundedQueue<T> { 
private Object[] items,; 
// 添加 的 下 标 ， 删 除 的 下 标 和 数组 当前 数量 


private int addIndex，removeIndex，count ; 





private Lock lock = New ReentrantLock(); 
private Condition notEmpty = lock.newCondition(); 
private Condition notFull = lock.newCondition(); 


public BoundedQueue(int size) { 
items = new Object[sizel]; 

















} 

// 添加 一 个 元 素 ， 如 果 数 组 满 ， 则 添加 线程 进入 等 待 状态 ， 直 到 有 "空位 " 

public void add(T t) throws InterruptedException { 
lock.1lock(); 





try { 
while (count == items.1length) 
NotFull.await( ); 
items[addIndex] = t; 
if (++addIndex == items.1length) 
addIndex = 0; 
++COunt 
notEmpty.Signal() ， 
} finally { 
lock.unlock(); 
} 


} 
// 由 头 部 删除 一 个 元 素 ， 如 果 数 组 空 ， 则 删除 线程 进入 等 待 状 态 ， 直 到 有 新 添加 元 素 
@Suppresswarnings("unchecked") 
public T remove() throws InterruptedException { 
lock.1lock(); 


try { 






































while (count == 0) 
notEmpty .await( ); 
Object x = items[removeIndex]; 
If (++removeIndex == items.length) 
removeIndex = 0; 
--count; 
notFull.signal( ); 
return (T) x; 
} finally { 
lock.unlock(); 
} 





述 示 例 中 ，BoundedQueue 通 过 add(Tt) 方 法 添加 一 个 元 素 ， 通 过 
remove() 方 法 移出 一 个 元 素 。 以 添加 方法 为 例 。 





首先 需要 获得 锁 ， 目 的 是 确保 数组 修改 的 可 见 性 和 排他 性 。 当 数组 


数量 等 于 数组 长 度 时 ， 表 示 数 组 已 满 ， 则 调用 notFull.await0， 当 前 线程 
随 之 释放 锁 并 进入 等 待 状态。 如 果 数 组 数量 不 等 于 数组 长 度 ， 表 示 数 组 
未 满 ， 则 添加 元 素 到 数组 中 ， 同 时 通知 等 竺 在 notEmpty 上 的 线程 ， 数 组 
中 己 经 有 新 元 系 可 以 获取 。 





在 添加 和 删除 方法 中 使 用 whbile 循 环 而 非 过 判断 ， 目 的 是 防止 过 早 或 
意外 的 通知 ， 只 有 条 件 符 合 才能 够 退出 循环 。 回 想 之 前 提 到 的 等 符 / 通 
知 的 经 典范 式 ， 二 者 是 非常 类 似 的 。 





5.6.2 ” Condition 的 实现 分 析 


ConditionObject 是 同步 器 AbstractQueuedSynchronizer 的 内 部 类 ， 因 
为 Condition 的 操作 需要 获取 相关 联 的 锁 ， 所 以 作为 同步 器 的 内 部 类 也 较 
为 合理 。 每 个 Condition 对 象 都 包含 着 一 个 队列 《以 下 称 为 等 竺 队列 ) ， 
该 队列 是 Condition 对 象 实现 等 待 /通知 功能 的 关键 。 


下 面 将 分 析 Condition 的 实现 ， 主 要 包括 : 等 竺 队列、 等 待 和 通知 ， 
下 面 提 到 的 Condition 如 果 不 加 说 明 均 指 的 是 ConditionObject。 


1. 等 竺 队列 





等 待 队列 是 一 个 FIFO 的 队列 ， 在 队列 中 的 每 个 节点 都 包含 了 一 个 线 
程 引 用 ， 该 线程 就 是 在 Condition 对 象 上 等 待 的 线程 ， 如 果 一 个 线程 调用 
了 Condition.await() 方 法 ， 那 么 该 线程 将 会 释放 锁 、 构 造成 节点 加 入 等 待 
队列 并 进入 等 待 状态 。 事 实 上 ， 节 点 的 定义 复 用 了 同步 器 中 节点 的 定 
义 ， 也 就 是 说 ， 同 步 队 列 和 等 待 队列 中 节点 类 型 都 是 同步 器 的 静态 内 部 


类 AbstractQueuedSynchronizer.Node。 





一 个 Condition 包 含 一 个 等 待 队列 ，Condition 拥 有 首 节 点 
CfirstWaiter) 和 尾 节 点 (lastWaiter) 。 当 前 线程 调用 Condition.await() 
方法 ， 将 会 以 当前 线程 构造 节点 ， 并 将 节点 从 尾部 加 入 等 竺 队列 ， 等 竺 


队列 的 基本 结构 如 图 5-9 所 示 。 





Condition 


firstWaiter 节点 节点 1 
1 1 
IlastWaiter nextWaiter-|- - - >! nextWaiter | 


Me ee ee mm 





一 
~ -ed 
一 一 ae 
了 一 吓人 


图 5-9 等待 队列 的 基本 结构 


如 图 所 示 ，Condition 拥 有 首尾 市 点 的 引用 ， 而 新 增 节 点 只 需要 将 原 
有 的 尾市 太 nextWaiter 指 向 它 ， 并 且 更 新 尾市 点 即 可 。 上 述 市 点 引用 更 
新 的 过 程 并 没有 使 用 CAS 保 证 ， 原 因 在 于 调用 await() 方 法 的 线程 必定 是 
获取 了 锁 的 线程 ， 也 束 是 说 该 过 程 是 由 锁 来 保证 线程 安全 的 。 


在 Object 的 监视 器 模型 上 ， 一 个 对 象 拥 有 一 个 同步 队列 和 等 竺 队 
列 ， 而 并 发 包 中 的 Lock〈 更 确切 地 说 是 同步 器 ) 拥有 一 个 同步 队列 和 多 
个 等 待 队列 ， 其 对 应 关系 如 图 5-10 所 示 。 


一 一 二 一 一 一 一 一 
节点 节点 节点 节点 节点 


prev prev prev prev prev 
next—| >| next nex- | >| next- >| next 


firstWaiter 节点 节点 节点 
IastWoaiter 着 nextWaiter nextWaiter Dt nextWaiter 
firstWaiter 节点 节点 节点 
IastWoaiter | nextWaiter El nextWaiter We nextWaiter 


图 5-10 ”同步 队列 与 等 待 队 列 








如 图 所 示 ，Condition 的 实现 是 同步 器 的 内 部 类 ， 因 此 每 个 Condition 
实例 都 能 够 访问 同步 器 提供 的 方法 ， 相 当 于 每 个 Condition 都 拥有 所 属 同 
步 器 的 引用 。 


2. 等 待 


调用 Condition 的 await(0 方 法 《或 者 以 await 开 头 的 方法 ) ， 会 使 当前 
线程 进入 等 待 队 列 并 释放 锁 ， 同 时 线程 状态 变 为 等 待 状态 。 当 从 await() 
方法 返回 时 ， 当 前 线程 一 定 获 取 了 Condition 相 关联 的 锁 。 


如 果 从 队列 《同步 队列 和 等 待 队列 ) 的 角度 看 await(0 方 法 ， 当 调用 
await() 方 法 时 ， 相 当 于 同步 队列 的 首 节 点 (获取 了 锁 的 市 点) 移动 到 





Condition 的 等 竺 队列 中 。 
Condition 的 await(0) 方 法 ， 如 代码 清单 5-22 所 示 。 


代码 清单 5-22 ”ConditionObject 的 await 方 法 





public final void await() throws InterruptedException { 

If (Thread.interrupted()) 
throw new InterruptedException(); 

// 当前 线程 加 入 等 待 队列 

Node node = addConditionwaiter(); 

// 释放 同步 状态 ， 也 就 是 释放 锁 

int SavedState = fullyRelease(node); 

int interruptMode = 0 

while (!isOnSyncQueue(node)) { 
LockSupport.park(this); 
if ((interruptMode = checkIinterruptwhilewaiting(node)) != 0) 

break; 


If (acquireQueued(node, savedState) && interruptMode != THROW_IE) 
interruptMode = REINTERRUPT ， 

If (node.nextwaiter != null) 
unlinkCancelledwaiters(); 

if (interruptMode != 0) 
reportIinterruptAfterwait(interruptMode); 





调用 该 方法 的 线程 成 功 获取 了 锁 的 线程 ， 也 就 是 同步 队列 中 的 首 节 
所， 该 方法 会 将 当前 线程 构造 成 节点 并 加 入 等 等 队列 中 ， 然 后 释放 同步 
状态 ， 唤 醒 同 步 队 列 中 的 后 继 节点 ， 然 后 当前 线程 会 进入 等 待 状态 。 


当 等 竺 队列 中 的 节点 被 唤醒 ， 则 唤醒 节点 的 线程 开始 符 试 获取 同步 
状态 。 如 果 不 是 通过 其 他 线程 调用 Condition.signal() 方 法 唤醒 ， 而 是 对 
等 待 线程 进行 中 断 ， 则 会 抛 出 InterruptedException。 


如 果 从 队列 的 角度 去 看 ， 当 前 线程 加 入 Condition 的 等 竺 队列 ， 该 过 


程 如 图 5-11 示 。 


如 图 所 示 ， 同 步 队 列 的 首 市 点 并 不 会 直接 加 入 等 竺 队列 ， 而 是 通过 
addConditionWaiter() 方 法 把 当前 线程 构造 成 一 个 新 的 节点 并 将 其 加 入 等 
竺 队列 中 。 


3. 通 知 


调用 Condition 的 signal0 方 法 ， 将 会 唤醒 在 等 待 队列 中 等 竺 时间 最 长 
的 节点 〈 首 布点 ) ， 在 唤醒 节点 之 前 ， 会 将 节操 移 到 同步 队列 中 。 


Condition 的 signal() 方 法 ， 如 代码 清单 5-23 所 示 。 





图 5-11 当前 线程 加 入 等 待 队列 


代码 清单 5-23 ”ConditionObject 的 signal 方 法 





public final void signal() { 


if (!isHeldExclusively()) 
throw new IllegalMonitorStateException(); 


Node first = firstwaiter,; 


if (first != null) 
doSsignal(first); 





调用 该 方法 的 前 置 条 件 是 当前 线程 必须 获取 了 锁 ， 可 以 看 到 signal() 
方法 进行 了 isHeldExclusively() 检 查 ， 也 就 是 当前 线程 必须 是 获取 了 锁 的 
线程 。 接 着 获取 等 竺 队列 的 首 节 点 ， 将 其 移动 到 同步 队列 并 使 用 
LockSupport 唤 醒 节 点 中 的 线程 。 


节点 从 等 待 队 列 移动 到 同步 队列 的 过 程 如 图 5-12 所 示 。 


firstWaliter 
|ostWaiter 





图 5-12 节点 从 等 待 队 列 移动 到 同步 队列 


通过 调用 同步 器 的 enq(Node node) 方 法 ， 等 竺 队列 中 的 头 节 点 线程 
安全 地 移动 到 同步 队列 。 当 节点 移动 到 同步 队列 后 ， 当 前 线程 再 使 用 


LockSupport 唤 醒 该 节点 的 线程 。 


被 唤醒 后 的 线程 ， 将 从 await0) 方 法 中 的 while 循 环 中 退出 
(isOnSyncQueue(Node node) 方 法 返回 true， 市 点 已 经 在 同步 队列 中 )， 
进而 调用 同步 器 的 acquireQueued0 方 法 加 入 到 获取 同步 状态 的 苑 争 中 。 


成 功 获 取 同 步 状态 (或 者 说 锁 ) 之 后 ， 被 唤醒 的 线程 将 从 先前 调用 
的 await0) 方 法 返回 ， 此 时 该 线程 已 经 成 功 地 获取 了 锁 。 
Condition 的 signalAHO 方 法 ， 相 当 于 对 等 竺 队列 中 的 每 个 节点 均 执 


行 一 次 signal0) 方 法 ， 效 果 就 是 将 等 每 队列 中 所 有 市 扣 全 部 移动 到 同步 队 
列 中 ， 并 唤醒 每 个 市 点 的 线程 。 








5.7 本章 小 结 








本 章 介 绍 了 Java 并 发 包 中 与 锁 相 关 的 API 和 组 件 ， 通 过 示例 讲述 了 
这 些 API 和 组 件 的 使 用 方式 以 及 需要 注意 的 地 方 ， 并 在 此 基础 上 详细 地 
剖析 了 队列 同步 器 、 重 入 锁 、 读 写 锁 以 及 Condition 等 API 和 组 件 的 实现 
细节 ， 只 有 理解 这 些 API 和 组 件 的 实现 细节 才能 够 更 加 准确 地 运用 它 
们 。 





第 6 草 ”Java 并 及 容 髓 和 框 以 





Java 程 序 员 进 行 并 发 编程 时 ， 相 比 于 其 他 语言 的 程序 员 而 言 要 倍 感 
羊 福 ， 因 为 并 发 编程 大 师 Doug Lea 不 遗 余力 地 为 Java 开 发 者 提供 了 非常 
多 的 并 及 容器 和 框架 。 本 章 让 我 们 一 起 来 见识 一 下 大 师 操 刀 编写 的 并 友 
容 句 和 框 名 ， 并 通过 每 节 的 原理 分 析 一 起 来 学 习 如 何 设计 出 精妙 的 并 发 
程序 。 








6.1 ”ConcurrentHashMap 的 实现 原理 与 使 用 


ConcurrentHashMap 是 线程 安全 有 旦 高 效 的 HashMap。 本 节 让 我 们 一 
起 研究 一 下 该 容器 是 如 何在 保证 线程 安全 的 同时 又 能 保证 高 效 的 操作 。 





6.1.1 为 什么 要 使 用 ConcurrentHashMap 


在 并 及 编程 中 使 用 HashMap 可 能 导致 程序 死 循 坏 。 而 使 用 线程 安全 
的 HashTable 效 率 叉 非常 低下 ， 基 于 以 上 两 个 原因 ， 便 有 了 


ConcurrentHashMap 的 登场 机 会 。 
(1) 线程 不 安全 的 HashMap 


在 多 线程 环境 下 ， 使 用 HashMap 进 行 put 操 作 会 引起 死 循环 ， 导 致 
CPU 利用 率 接 近 100%， 所 以 在 并 发 情况 下 不 能 使 用 HashMap。 例 如 ， 执 
行 以 下 代码 会 引起 死 循环 。 








final HashMap<String, String> map = new HashMap<String, String>(2); 
Thread t = new Thread(new Runnable() { 
@Override 
public void run() { 
for (int i = 0; i < 10000; i++) { 
new Thread(new Runnable() { 


@Override 
public void run() { 
map.put(UUID.randomUUID().toString(), ""); 
}, "ftf" + i).start(); 
} 
} 
Fy "ftf"); 
t.start(); 
t .join(); 





HashMap 在 并 发 执行 put 操 作 时 会 引起 死 循 环 ， 是 因为 多 线程 会 导致 
HashMap 的 Entry 链 表 形 成 环形 数据 结构 ， 一 旦 形成 环形 数据 结构 ， 
Entry 的 next 节 点 永远 不 为 空 ， 就 会 产生 死 循环 获取 Entry。 


(2) 效率 低下 的 HashTable 


HashTable 容 器 使 用 synchronized 来 保证 线程 安全 ， 但 在 线程 范 争 激 
烈 的 情况 下 HashTable 的 效率 非常 低下 。 因 为 当 一 个 线程 访问 HashTable 
的 同步 方法 ， 其 他 线程 也 访问 HashTable 的 同步 方法 时 ， 会 进入 阻塞 或 
轮 询 状态 。 如 线程 1 使 用 put 进 行 元 素 添加 ， 线 程 2 不 但 不 能 使 用 put 方 法 
添加 元 素 ， 也 不 能 使 用 get 方 法 来 获取 元 素 ， 所 以 竞争 越 激 烈 效 率 越 
低 。 


(3) ConcurrentHashMap 的 锁 分 段 技术 可 有 效 提升 并 发 访问 率 





HashTable 容 右 在 苑 争 激烈 的 并 发 环境 下 表现 出 效率 低下 的 原因 是 
所 有 访问 HashTable 的 线程 者 必须 苋 搜 同 一 把 锁 ， 假 如 容 右 里 有 多 把 
锁 ， 每 一 把 锁 用 于 锁 容 需 其 中 一 部 分 数据 ， 那 么 当 多 线程 访问 容器 里 不 
同 数据 段 的 数据 时 ， 线 程 间 融 不 会 存在 锁 竞 争 ， 从 而 可 以 有 效 提 高 并 发 
访问 效率 ， 这 就 是 ConcurrentHashMap 所 使 用 的 锁 分 段 技术 。 首 先 将 数 
气 分 成 一 段 一 段 地 存储 ， 然 后 给 每 一 段 数据 配 一 把 锁 ， 当 一 个 线程 占用 
锁 访 问 其 中 一 个 段 数 据 的 时 候 ， 其 他 段 的 数据 也 能 被 其 他 线程 访问 。 








6.1.2 ”ConcurrentHashMap 的 结构 


通过 ConcurrentHashMap 的 类 图 来 分 析 ConcurrentHashMap 的 结构 ， 
如 图 6-1 所 示 。 


ConcurrentHashMap 是 由 Segment 数 组 结构 和 HashEntry 数 组 结构 组 
成 。Segment 是 一 种 可 重 入 锁 (ReentrantLock) ， 在 ConcurrentHashMap 
里 扮演 锁 的 角色 ;， HashEntry 则 用 于 存储 键 值 对 数据 。 一 个 
ConcurrentHashMap 里 包含 一 个 Segment 数 组 。Segment 的 结构 和 
HashMap 类 似 ， 是 一 种 数组 和 链表 结构 。 一 个 Segment 里 包含 一 个 
HashEntry 数 组 ， 每 个 HashEntry 是 一 个 链表 结构 的 元 素 ， 每 个 Segment 守 
护 着 一 个 HashEntry 数 组 里 的 元 素 ， 当 对 HashEntry 数 组 的 数据 进行 修改 
时 ， 必 须 首 先 获得 与 它 对 应 的 Segment 锁 ， 如 图 6-2 所 示 。 














pkg java.util.concurrent 












ConcurrentHashMap <K, V> 
- segments : Segment <K,V>1] 


+ get0 :V 

+ PuUt0 : V 

+ size0) : int 

+ remove( : V 

+ putifAbsent0 : V 





AbstractMap <K, V> 





Segment<K,V> 
-~ count : int 
~- modCount : int 
- threshold : int 
- table : HashEntry<K,V> 
-loadFactor : int 


+ put(0 :V 
+ get(0 : V 














~ next: HashEntry<K,V> 
-key:V 
- segments : int 


-Value :Vv 


图 6-1 ConcurrentHashMap 的 类 图 


ConcurretnHashMap 







Seg ment[] | vegment1 Segment2 


HashEntry[] HashEntry1.1 HashEntry1.2 HashEntry2.1 


图 6-2 ”ConcurrentHashMap 的 结构 图 


6.1.3 ”ConcurrentHashMap 的 初始 化 


ConcurrentHashMap 初 始 化 方法 是 通过 initialCapacity、loadFactor 和 
concurrencyLevel 等 儿 个 参数 来 初始 化 segment 数 组 、 段 偏 移 量 
segmentShift、 上 段 掩 码 segmentMask 和 每 个 segment 里 的 HashEntry 数 组 来 
实现 的 。 


1. 初 始 化 segments 数 组 


让 我 们 来 看 一 下 初始 化 segments 数 组 的 源 代码 。 





if (concurrencyLevel > MAX_SEGMENTS ) 
concurrencyLevel = MAX_ SEGMENTS,; 
int sshift = 0; 
int ssize = 1; 
while (ssize < concurrencyLevel) { 
++SShift; 
ssize <<= 1; 


} 

SegmentShift = 32 - sshift; 

segmentMask = ssize - 1; 

this.segments = Segment.newArray(ssize); 





由 上 面 的 代码 可 知 ，segments 数 组 的 长 度 ssize 是 通过 
concurrencyLevel 计 算得 出 的 。 为 了 能 通过 按 位 与 的 散 列 算法 来 定位 
segments 数 组 的 索引 ， 必 须 保证 segments 数 组 的 长 度 是 2 的 N 次 方 

(power-of-two size) ， 所 以 必须 计算 出 一 个 大 于 或 等 于 
concurrencyLevel 的 最 小 的 2 的 N 次 方 值 来 作为 segments 数 组 的 长 度 。 假 如 


concurrencyLevel 等 于 14、15 或 16，ssize 都 会 等 于 16， 即 容器 里 锁 的 个 数 


也 是 16。 


© 注意 ”concurrencyLevel 的 最 大 值 是 65535， 这 意味 着 segments 数 


组 的 长 度 最 大 为 65536， 对 应 的 二 进 制 是 16 位 。 


2. 初 始 化 segmentShift 和 segmentMask 





这 两 个 全 局 变量 需要 在 定位 segment 时 的 散 列 算法 里 使 用 ，sshift 等 
于 ssize 从 1 问 左 移 位 的 次 数 ， 在 默认 情况 下 concurrencyLevel 等 于 16，1 需 
要 向 左 移 位 移动 4 次 ， 所 以 sshift 等 于 4。segmentShift 用 于 定位 参与 散 列 
运算 的 位 数 ，segmentShift 等 于 32 减 sshift， 所 以 等 于 28， 这 里 之 所 以 用 
32 是 因为 ConcurrentHashMap 里 的 hash() 方 法 输出 的 最 大 数 是 32 位 的 ， 后 
面 的 测试 中 我 们 可 以 看 到 这 点 。segmentMask 是 散 列 运算 的 掩 码 ， 等 于 
ssize 减 1， 即 15， 掩 码 的 二 进 制 各 个 位 的 值 都 是 1。 因 为 ssize 的 最 大 长 度 
是 65536， 所 以 segmentShift 最 大 值 是 16，segmentMask 最 大 值 是 65535， 
对 应 的 二 进 制 是 16 位 ， 每 个 位 都 是 1。 








3. 初 始 化 每 个 segment 


输入 参数 initialCapacity 是 ConcurrentHashMap 的 初始 化 容量 ， 
loadfactor 是 每 个 segment 的 负载 因子 ， 在 构造 方法 里 需要 通过 这 两 个 参 
数 来 初始 化 数组 中 的 每 个 segment。 


一 


if (initialCapacity > MAXIMUM_ CAPACITY) 

initialCapacity = MAXIMUM_CAPACITY 

int c = initialCapacity / ssize; 

If (c * ssize < initialCapacity) 
++C; 

int cap = 1; 

while (cap < c) 
cap <<= 1; 

for (int i = 0; i < this.segments.length; ++i) 
this.segments[i] = new Segment<K,V>(cap, loadFactor); 








上 面 代码 中 的 变量 cap 就 是 segment 里 HashEntry 数 组 的 长 度 ， 它 等 于 
initialCapacity 除 以 ssize 的 倍数 c， 如 果 c 大 于 1， 束 会 取 大 于 等 于 c 的 2 的 N 
次 方 值 ， 所 以 cap 不 是 1， 就 是 2 的 N 次 方 。segment 的 容量 threshold 二 

Gint) capxloadFactor， 默 认 情 况 下 initialCapacity 等 于 16，loadfactor 等 于 
0.75， 通 过 运算 cap 等 于 1，threshold 等 于 零 。 


6.1.4 定位 Segment 


既然 ConcurrentHashMap 使 用 分 段 锁 Segment 来 保护 不 同 段 的 数据 ， 
那么 在 插入 和 获取 元 素 的 时 候 ， 必 须 先 通过 散 列 算法 定位 到 Segment。 
可 以 看 到 ConcurrentHashMap 会 首先 使 用 Wang/Jenkins hash 的 变种 算法 对 
元 素 的 hashCode 进 行 一 次 再 散 列 。 





private static int hash(int h) { 
h += (h << 15) ^ 0xffffcd7d ， 
h A= (h >>> 10); 
h += (h << 3); 
h A= (h >>> 6); 
h += (h << 2) + (h << 14); 
return h ^ (h >>> 16); 





之 所 以 进行 再 散 列 ， 目 的 是 减少 散 列 冲突 ， 使 元 素 能 够 均匀 地 分 布 
在 不 同 的 Segment 上 ， 从 而 提高 容 需 的 存 取 效 率 。 假 如 散 列 的 质量 差 到 
极点 ， 那 么 所 有 的 元 素 都 在 一 个 Segment 中 ， 不 仅 存 取 元 素 缓慢 ， 分 段 
锁 也 会 失去 意义 。 笔 者 做 了 一 个 测试 ， 不 通过 再 散 列 而 直接 执行 散 列 计 
算 。 








System,out.println(Integer,parseInt("0001111"，2) & 15) 
System,out.println(Integer,parseInt("0011111"，2) & 15) 
System,out.println(Integer,parseInt("0111111"，2) & 15) 
System,out.println(Integer,parseInt("1111111"，2) & 15) 





计算 后 输出 的 散 列 值 全 是 15， 通 过 这 个 例子 可 以 有 发现， 如 果 不 进 行 





再 散 列 ， 散 列 冲突 会 非常 严重 ， 因 为 只 要 低位 一 样 ， 无 论 高 位 是 什么 
数 ， 其 散 列 值 总 是 一 样 。 我 们 再 把 上 面 的 三 进 制 数据 进行 再 散 列 后 结果 
如 下 《为 了 方便 阅读 ， 不 足 32 位 的 高 位 补 了 0， 每 隔 4 位 用 紧 线 分 割 
人 





0100 | 0111 | 0110 | 0111 | 1101 | 1010 | 0100 | 1110 
1111 | 0111 | 0100 | 0011 | 0000 | 0001 | 1011 | 1000 
©0111 | 0111 | 0110 | 1001 | 0100 | 0110 | 0011 | 1110 
1000 | 0011 | 0000 | 0000 | 1100 | 1000 | 0001 | 1010 





可 以 发 现 ， 每 一 位 的 数据 都 散 列 开 了 ， 通 过 这 种 再 散 列 能 让 数字 的 
每 一 位 都 参加 到 散 列 运算 当中 ， 从 而 减少 散 列 冲突 。 
ConcurrentHashMap 通 过 以 下 散 列 算法 定位 segment。 





final Segment<K,V> segmentFor(int hash) { 
return segments[(hash >>> segmentShift) & segmentMask]; 
} 





默认 情况 下 segmentShift 为 28，segmentMask 为 15， 再 散 列 后 的 数 最 
大 是 32 位 二 进 制 数 据 ， 癌 右 无 符号 移动 28 位 ， 意 思 是 让 高 4 位 参与 到 散 
列 运算 中 ， (hash>>>segmentShift) &segmentMask 的 运算 结果 分 别 是 
4、15、7 和 8， 可 以 看 到 散 列 值 没有 发 生 冲 突 。 











6.1.5 ”ConcurrentHashMap 的 操作 


本 节 介绍 ConcurrentHashMap 的 3 种 操作 一 一 get 操 作 、put 操 作 和 size 


1.get 操 作 


Segment 的 get 操 作 实 现 非 常 简 单 和 高 效 。 先 经 过 一 次 再 散 列 ， 然 后 
使 用 这 个 散 列 值 通过 散 列 运算 定位 到 Segment， 再 通过 散 列 算法 定位 到 
元 素 ， 代 码 如 下 。 





public V get(Object key) { 
int hash = hash(key.hashCode()); 
return segmentFor(hash).get(key, hash); 





get 操 作 的 高 效 之 处 在 于 整个 get 过 程 不 需要 加 锁 ， 除 非 读 到 的 值 是 

空 才 会 加 锁 重 读 。 我 们 知道 HashTable 容 器 的 get 方 法 是 需要 加 锁 的 ， 那 
么 ConcurrentHashMap 的 get 操 作 是 如 何 做 到 不 加 锁 的 呢 ? 原因 是 它 的 get 
方法 里 将 要 使 用 的 共享 变量 都 定义 成 volatile 类 型 ， 如 用 于 统计 当前 
Segement 大 小 的 count 字 段 和 用 于 存储 值 的 HashEntry 的 value。 定 义 成 
volatile 的 变量 ， 能 够 在 线程 之 间 保 持 可 见 性 ， 能 够 被 多 线程 同时 读 ， 并 
且 保 证 不 会 读 到 过 期 的 值 ， 但 是 只 能 被 单线 程 写 《有 一 种 情况 可 以 被 多 
线程 号 ， 就 是 写 入 的 值 不 依赖 于 原 值 ) ， 在 get 操 作 里 只 需要 读 不 需要 

















写 共 训 变量 count 和 value， 所 以 可 以 不 用 加 锁 。 之 所 以 不 会 读 到 过 期 的 
值 ， 是 因为 根据 Java 内 存 模型 的 happen before 原 则 ， 对 volatile 字 段 的 写 
入 操作 先 于 读 操 作 ， 即 使 两 个 线程 同时 修改 和 获取 Volatile 变量 ，get 操 
作 也 能 拿 到 最 新 的 值 ， 这 是 用 volatile 蔡 换 锁 的 经 典 应 用 场景 。 





transient volatile int count 
volatile V value; 





在 定位 元 素 的 代码 里 我 们 可 以 发 现 ， 定 位 HashEntry 和 定位 Segment 
的 散 列 算法 虽然 一 样 ， 都 与 数组 的 长 度 减 去 1 再 相 “ 与 ?， 但 是 相 “ 与 ”的 
值 不 一 样 ， 定 位 Segment 使 用 的 是 元 素 的 hashcode 通 过 再 散 列 后 得 到 的 
值 的 高 位 ， 而 定位 HashEntry 直 接 使 用 的 是 再 散 列 后 的 值 。 其 目的 是 避 
免 两 次 散 列 后 的 值 一 样 ， 虽 然 元 素 在 Segment 里 散 列 开 了 ， 但 是 却 没 有 
在 HashEntry 里 散 列 开 。 


























hash >>> segmentShift) & segmentMask // 定位 Segment 所 使 用 的 hash 算 法 
int index = hash & (tab.length - 1); // 定位 HashEntry 所 使 用 的 hash 算 法 
Le 
2.put 操 作 





由 于 put 方 法 里 需要 对 共享 变量 进行 号 入 操作 ， 上 所 以 为 了 线程 安 
全 ， 在 操作 共享 变量 时 必须 加 锁 。put 方 法 首先 定位 到 Segment， 然 后 在 
Segment 里 进行 插入 操作 。 插 入 操作 需要 经 历 两 个 步骤 ， 第 一 步 判断 是 
否 需要 对 Segment 里 的 HashEntry 数 组 进行 扩容 ， 第 二 步 定 位 添加 元 素 的 








位 置 ， 然 后 将 其 放 在 HashEntry 数 组 里 。 


在 插入 元 素 前 会 先 判断 Segment 里 的 HashEntry 数 组 是 否 超过 容量 
Cthreshold) ， 如 果 超 过 阔 值 ， 则 对 数组 进行 扩容 。 值 得 一 提 的 是 ， 
Segment 的 扩容 判断 比 HashMap 更 恰当 ， 因 为 HashMap 是 在 插入 元 素 后 
判断 元 素 是 否 已 经 到 达 容 量 的 ， 如 果 到 达 了 就 进行 扩容 ， 但 是 很 有 可 能 
扩容 之 后 没有 新 元 素 插入 ， 这 时 HashMap 就 进行 了 一 次 无 效 的 扩容 。 














(2) 如何 扩容 











在 扩容 的 时 候 ， 首 先 会 创建 一 个 容量 是 原来 容量 两 倍 的 数组 ， 然 后 
将 原 数 组 里 的 元 素 进 行 再 散 列 后 插入 到 新 的 数组 里 。 为 了 高 效 ， 
ConcurrentHashMap 不 会 对 整个 容器 进行 扩容 ， 而 只 对 某 个 segment 进 行 


扩容 。 


3.size 控 作 


如 果 要 统计 整个 ConcurrentHashMap 里 元 素 的 大 小 ， 就 必须 统计 所 
有 Segment 里 元 素 的 大 小 后 求 和 。Segment 里 的 全 局 变量 count 是 一 个 
Volatile 变量， 那么 在 多 线程 场景 下 ， 是 不 是 直接 把 所 有 Segment 的 count 
相 加 就 可 以 得 到 整个 ConcurrentHashMap 大 小 了 呢 ? 不 是 的 ， 虽 然 相 加 
时 可 以 获取 每 个 Segment 的 count 的 最 新 值 ， 但 是 可 能 累加 前 使 用 的 count 

















发 生 了 变化 ， 那 么 统计 结果 就 不 准 了 。 所 以 ， 最 安全 的 做 法 是 在 统计 
size 的 时 候 把 所 有 Segment 的 put、remove 和 clean 方 法 全 部 锁 住 ， 但 是 这 
种 做 法 显然 非常 低 效 。 





因为 在 累加 count 操 作 过 程 中 ， 之 前 累加 过 的 count 发 生变 化 的 几率 
非常 小 ， 所 以 ConcurrentHashMap 的 做 法 是 先 尝试 2 次 通过 不 锁 住 
Segment 的 方式 来 统计 各 个 Segment 大 小 ， 如 宋 统 计 的 过 程 中 ， 容 器 的 
count 发 生 了 变化 ， 则 再 采用 加 锁 的 方式 来 统计 所 有 Segment 的 大 小 。 





那么 ConcurrentHashMap 是 如 何 判 断 在 统计 的 时 候 容 器 是 否 发 生 了 
变化 呢 ? 使 用 modCount 变 量 ， 在 put、remove 和 clean 方 法 里 操作 元 素 前 
都 会 将 变量 modCount 进 行 加 1， 那 么 在 统计 size 前 后 比较 modCount 是 否 
发 生变 化 ， 从 而 得 知 容器 的 大 小 是 否 发 生变 化 。 


6.2 ConcurrentLinkedQueue 


在 并 及 编程 中 ， 有 时 候 需 要 使 用 线程 安全 的 队列 。 如 果 要 实现 一 个 
线程 安全 的 队列 有 两 种 方式 : 一 种 是 使 用 阻 蜂 算法 ， 男 一 种 是 使 用 非 阻 
塞 算 法 。 使 用 阻 豆 算法 的 队列 可 以 用 一 个 锁 〈 入 队 和 出 队 用 同一 把 锁 ) 
或 两 个 锁 《〈 入 队 和 出 队 用 不 同 的 锁 ) 等 方式 来 实现 。 非 阻塞 的 实现 方式 
则 可 以 使 用 循环 CAS 的 方式 来 实现 。 本 节 让 我 们 一 起 来 研究 一 下 Doug 
Lea 是 如 何 使 用 非 阻 塞 的 方式 来 实现 线程 安全 队列 
ConcurrentLinkedQueue 的 ， 相 信 从 大 师 身 上 我 们 能 学 到 不 少 并 发 编程 的 
技巧 。 














ConcurrentLinkedQueue 是 一 个 基于 链接 节点 的 无 界线 程 安全 队列 ， 
它 采 用 先进 先 出 的 规则 对 节点 进行 排序 ， 当 我 们 添加 一 个 元 素 的 时 候 ， 
它 会 添加 到 队列 的 尾部 ， 当 我 们 获取 一 个 元 素 时 ， 它 会 返回 队列 头 部 的 
元 素 。 它 采用 了 “wait-free” 算 法 〈 即 CAS 算 法 ) 来 实现 ， 该 算法 在 
Michael&Scott 算 法 上 进行 了 一 些 修 改 。 


6.2.1 ”ConcurrentLinkedQueue 的 结构 
通过 ConcurrentLinkedQueue 的 类 图 来 分 析 一 下 它 的 结构 ， 如 图 6-3 
所 示 。 


pkg java.util.concurrent 
;El, 


AbstractQueue- 











村 
ConcurrentLinkedQueue 


- head : Node<E> 

- tair : Node <E> 

+ offerle : E): boolean 
+ poll0 : E 


Node<E> 





- item : E 

- next : Node<E> 

+ casltem0 : boolean 

+ |azySetlteml) : boolean 








图 6-3 ”ConcuttentLinkedQueue 的 类 图 


ConcurrentLinkedQueue 由 head 节 点 和 tail 节 点 组 成 ， 每 个 节点 
CNode) 由 节点 元 素 〈item) 和 指 癌 下 一 个 节点 Cnext) 的 引用 组 成 ， 
节点 与 节点 之 间 就 是 通过 这 个 next 关 联 起 来 ， 从 而 组 成 一 张 链表 结构 的 
队列 。 默 认 情 况 下 head 节 点 存储 的 元 又 为 空 ，tail 节 点 等 于 head 节 点 。 











private transient volatile Node<E> tail = head; 





6.2.2 入 队列 


本 节 将 介绍 入 队列 的 相关 知识 。 
1. 入 队列 的 过 程 


入 队列 就 是 将 入 队 节 点 添加 到 队列 的 尾部 。 为 了 方便 理解 入 队 时 
队列 的 变化 ， 以 及 head 市 点 和 tail 节 点 的 变化 ， 这 里 以 一 个 示例 来 展开 介 
绍 。 假 设 我 们 想 在 一 个 队列 中 依次 插入 4 个 节点 ， 为 了 帮助 大 家 理解 ， 
每 添加 一 个 节操 束 做 了 一 个 队列 的 快照 图 ， 如 图 6-4 所 示 。 


图 6-4 所 示 的 过 程 如 下 。 


. 添加 元 素 1。 队 列 更 新 head 节 点 的 next 节 点 为 元 素 1 节 点 。 又 因为 
tail 节 点 默认 情况 下 等 于 head 节 点 ， 所 以 它们 的 next 节点 都 指向 元 素 1 节 


点 O 


. 添加 元 素 2。 队 列 首先 设置 元 素 1 节 点 的 next 节点 为 元 素 2 节 点 ， 然 


后 更 新 tail 节 点 指向 元 素 2 节 点 。 


添加 元 素 1 ”> 
head 节 点 


添加 元 素 ” head 节 点 
添加 元 素 3 head 节 点 
添加 元 素 4 head 节 点 


图 6-4 ”队列 添加 元 素 的 快照 图 
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四 添加 元 素 4 > 几 过 
元 素 4， 设 置 元 素 3 的 next 节 点 为 元 素 4 节 点 ， 然 后 3 
™ [RSS jAS rs 将 tall TP 占 


指向 元 素 4 节 点 。 





通过 调试 入 队 过 程 并 观 多 
ee ee en 
we 
Sa 
nid 
a 点 不 忆 是 尾 节 点 《理解 这 一 点 对 于 我 们 研究 源码 会 


过 对 上 面 的 分 析 ， 我 们 从 单线 程 入 队 的 角度 理解 了 入 队 过 程 ， 但 
古 多 个 线程 同时 进行 入 队 的 情况 残 变 得 更 加 复杂 了 ， 因 为 可 能 会 出 现 其 
他 线程 插队 的 情况 。 如 果 有 一 个 线程 正在 入 队 ， 那 么 它 必 须 先 获 取 尾 市 
扩 ， 然 后 设置 尾 节 点 的 下 一 个 节操 为 入 队 市 上 尽 ， 但 这 时 可 能 有 男 外 一 个 
线程 插队 了 ， 那 么 队列 的 尾 节点 就 会 及 生变 化 ， 这 时 当前 线程 要 暂停 入 
队 操作 ， 然 后 重新 获取 尾 节 点 。 让 我 们 再 通过 源码 来 详细 分 析 一 下 它 是 
如 何 使 用 CAS 算 法 来 入 队 的 。 











public boolean offer(E e) { 
If (e == null) throw new NullPointerException(); 
// 入 队 前 ， 创建 一 个 入 队 节 点 
Node E> n = new Node<E>(e); 
retry 
// 兄 箱 环 ， 入 队 不 成 功 反 复 入 队 。 
for (;;) { 
// 创建 一 个 指向 tail 节 点 的 引 
Node<E> t = tail; 
// Pp 用 来 表示 队列 的 尾 节点 ， 默 认 情 况 下 等 于 tail 节 点 。 
Node<E> p = t; 
for (int hops = 0; ; hops++) { 
// 获得 p 节 点 的 下 一 个 节点 。 
Node<E> next = succ(p); 
// next 节 点 不 为 空 ， 说 明 p 不 是 尾 节 点 ， 需 要 更 新 p 后 在 将 它 指 向 next 节 点 
If (next != nul1) { 
// 循环 了 两 次 及 其 以 上 ， 并 且 当 前 节点 还 是 不 等 于 尾 节 点 
if (hops > HOPS && t != tail 
continue retry; 
p = next,; 

















Kann 




































































} 
// 如 果 p 是 尾 节点 ， 则 设置 p 节 点 的 next 节 点 为 入 队 节 点 。 
else if (p.casNext(null, n)) { 
/* 如 果 tail 节 点 有 大 于 等 于 1 个 next 节 点 ， 则 将 入 队 节点 设置 成 tail 节 点 ， 
更 新 失败 了 也 没关系 ， 因 为 失败 了 表示 有 其 他 线程 成 功 更 新 了 tail 节 点 */ 




















if (hops >= HOPS) 





casTail(t，n); // 更 新 tail 节 点 ， 人 允许 失败 
return true; 





4 
// p 有 next 节 点 ,表示 p 的 next 节 点 是 尾 节点 ， 则 重新 设置 p 节 点 
else { 

p= succ(p); 

















从 源 代 码 角 度 来 看 ， 整 个 入 队 过 程 主要 做 两 件 事 情 : 第 一 是 定位 出 
尾 节 点 ;， 第 二 是 使 用 CAS 算 法 将 入 队 市 点 设置 成 尾市 上 的 next 市 皮 ， 如 
不 成 功 则 重 试 。 





2. 定 位 尾 节 点 


tail 节 点 并 不 总 是 尾 节 点 ， 所 以 每 次 入 队 都 必须 先 通 过 tail 节 点 来 找 
到 尾 节 点 。 尾 节点 可 能 是 tail 节 点 ， 也 可 能 是 tail 节 点 的 next 站 点 。 代 但 
中 循环 体 中 的 第 一 个 if 就 是 判断 tail 是 否 有 next 节 点 ， 有 则 表示 next 节 点 
可 能 是 尾 节 点 。 获 取 tail 节 点 的 next 节 点 需要 注意 的 是 p 节 点 等 于 p 的 next 
节点 的 情况 ， 只 有 一 种 可 能 就 是 p 节 点 和 p 的 next 节 点 都 等 于 空 ， 表 示 这 
个 队列 刚 初始 化 ， 正 准备 添加 节点 ， 所 以 需要 返回 head 节 点 。 获 取 p 节 
点 的 next 节 点 代码 如 下 。 























final Node<E> Succ(Node<E> p) { 
Node<E> next = p.getNext(); 
return (p == next) head : next,; 








3. 设 置 入 队 节 所 为 尾市 扩 


p.casNext (null，n) 方法 用 于 将 入 队 节 点 设置 为 当前 队列 尾 节 点 的 
next 证 点 ， 如 果 p 是 null， 表 示 p 古 当前 队列 的 尾 节 点 ， 如 果 不 为 null， 表 
示 有 其 他 线程 更 新 了 尾 节点 ， 则 需要 重新 获取 当前 队列 的 尾 节 点 。 








4.HOPS 的 设计 意图 


上 面 分 析 过 对 于 先进 先 出 的 队列 入 队 所 要 做 的 事情 是 将 入 队 市 点 设 
置 成 尾市 皮 ，doug lea 写 的 代码 和 人 逻辑 还 是 稍微 有 点 复杂 。 那 么 ， 我 用 
以 下 方式 来 实现 是 否 可 行 ? 














public boolean offer(E e) { 
If (e == null) 

throw new NullPointerException(); 

Node<E> n = new Node<E>(e); 

for (;;) { 
Node<E> t = tail; 
if (t.casNext(null, n) && casTail(t, n)) { 

return true; 

} 





让 tail 节 点 永远 作为 队列 的 尾 节点 ， 这 样 实 现代 码 量 非常 少 ， 而 且 
逻辑 清晰 和 易 懂 。 但 是 ， 这 么 做 有 个 缺点 ， 每 次 都 需要 使 用 循环 CAS 更 
新 tail 节 点 。 如 果 能 减少 CAS 更 新 tail 节 点 的 次 数 ， 就 能 提高 入 队 的 效 
率 ， 所 以 doug lea 使 用 hops 变 量 来 控制 并 减少 tail 节 点 的 更 新 频率 ， 并 不 
是 每 次 节点 入 队 后 都 将 tail 节 点 更 新 成 尾 节 点 ， 而 是 当 tail 节 点 和 尾 节 点 
的 距离 大 于 等 于 常量 HOPS 的 值 〈 默 认 等 于 1) 时 才 更 新 tail 太 点 ，tail 和 
尾 节点 的 距离 越 长 ， 使 用 CAS 更 新 tail 节 点 的 次 数 就 会 越 少 ， 但 是 距离 
越 长 带 来 的 负面 效果 就 是 每 次 入 队 时 定位 尾 节点 的 时 间 就 越 长 ， 因 为 循 
环 体 需要 多 循环 一 次 来 定位 出 尾 节点 ， 但 是 这 样 仍然 能 提高 入 队 的 效 
率 ， 因 为 从 本 质 上 来 看 它 通过 增加 对 volatile 变 量 的 读 操 作 来 减少 对 
volatile 变 量 的 写 操作 ， 而 对 volatile 变 量 的 写 操作 开销 要 远 远大 于 读 操 











作 ， 所 以 入 队 效率 会 有 所 提升 。 





private static final int HOPS = 1; 





Oi 入 队 方 法 永远 返回 ttue， 所 以 不 要 通过 返回 值 判断 入 队 


是 否 成 功 。 


6.2.3 ”出 队列 








出 队列 的 就 是 从 队列 里 返回 一 个 节点 元 素 ， 并 清空 该 节点 对 元 素 的 
引用 。 让 我 们 通过 每 个 节点 出 队 的 快照 来 观察 一 下 head 节 点 的 变化 ， 如 
图 6-5 所 示 。 


从 图 中 可 知 ， 并 不 是 每 次 出 队 时 都 更 新 headT 点 ， 当 head 节 点 里 有 
元 素 时 ， 直 接 弹 出 head 节 点 里 的 元 素 ， 而 不 会 更 新 head 放 点 。 只 有 当 
head 节 点 里 没有 元 又 时 ， 出 队 操 作 才 会 更 新 head 节 点 。 这 种 做 法 也 是 通 
过 hops 变 量 来 减少 使 用 CAS 更 新 head 节 点 的 消耗 ， 从 而 提高 出 队 效率 。 
让 我 们 再 通过 源码 来 深入 分 析 下 出 队 过 程 。 








弹 出 一 个 


节点 





为 空 


Qead 节点 ) 


图 6-5 ”队列 出 节点 快照 图 





public E poll() { 
Node<E> 


h = head; 





// p 表 示 头 节点 ， 需 要 出 队 的 节点 


Node<E> 


p= 


for (int hops = 0;; hops++) { 


// 更 新 头 节点 。 


// 获取 p 节 点 的 元 素 
E item = p.getIitem(); 
// 如 果 p 节 点 的 元 素 不 为 空 ， 使 用 CAS 设 置 p 节 点 引用 的 元 素 为 nul11， 
// 如 果 成 功 则 返回 p 节 点 的 元 素 。 
if (item != null && p.casIitem(item, null)) { 
if (hops >= HOPS) { 
// 将 p 节 点 下 一 个 节点 设置 成 head 节 点 
Node<E> q = p.getNext(); 
updateHead(h, (q != null) 9q : p); 





























} 


return item; 





} 

// 如 果 头 节点 的 元 素 为 空 或 头 节点 发 生 了 变化 ， 这 说 明 头 节点 已 经 被 另外 
// 一 个 线程 修改 了 。 那 么 获取 p 节 点 的 下 一 个 节点 

Node<E> next = Succ(p) 

// 如 果 p 的 下 一 个 节点 也 为 空 ， 说 明 这 个 队列 已 经 空 了 

if (next == nul1) { 





updateHead(h, p); 
break; 











// 如 果 下 一 个 元 素 不 为 空 ， 则 将 头 节 点 的 下 一 个 节点 设置 成 头 节 点 
p = next; 




















} 
return null; 














首先 获取 头 节 后 的 元 素 ， 然 后 判断 尖 市 点 元 素 古 否 为 空 ， 如 果 为 
空 ， 表 示 力 外 一 个 线程 已 经 进行 了 一 次 出 队 操 作 将 该 市 扣 的 元 素 取 走 ， 
如 宁 不 为 空 ， 则 使 用 CAS 的 方式 将 头 节 点 的 引用 设置 成 null， 如 果 CAS 
成 功 ， 则 直接 返回 头 节 点 的 元 素 ， 如 宋 不 成 功 ， 表 示 另 外 一 个 线程 已 经 
进行 了 一 次 出 队 操作 更 新 了 head 玉 点 ， 导 致 元 聚 发 生 了 变化 ， 需 要 重新 
获取 头 市 反 。 





6.3 Java 中 的 阻 团 队列 


本 节 将 介绍 什么 是 阻 赛 队列 ， 以 及 Java 中 阻塞 队列 的 4 种 处 理 方 
式 ， 并 介绍 Java 7 中 提供 的 7 种 阻塞 队列 ， 最 后 分 析 阻 塞 队 列 的 一 种 实现 
站 


6.3.1 什么 是 阻塞 队列 


阻塞 队列 〈BlockingQueue) 是 一 个 文 持 两 个 附加 操作 的 队列 。 这 
两 个 附加 的 操作 文 持 阻 堵 的 插入 和 移 除 方法 。 


1) 文 持 阻塞 的 插入 方法 : 意思 是 当 队 列 满 时 ， 队 列 会 阻塞 插入 元 
素 的 线程 ， 直 到 队列 不 满 。 


2) 文 持 阻 塞 的 移 除 方法 : 意思 是 在 队列 为 空 时 ， 获 取 元 素 的 线程 
会 等 待 队列 变 为 非 空 。 


阻 豆 队列 党 用 于 生产 者 和 消费 者 的 场景 ， 生 产 者 是 癌 队列 里 添加 元 
素 的 线程 ， 消 费 者 是 从 队列 里 取 元 素 的 线程 。 阻 暑 队 列 束 是 生产 者 用 来 
存放 元 素 、 消 费 者 用 来 获取 元 素 的 容器 。 


在 阻 窟 队列 不 可 用 时 ， 这 两 个 附加 操作 提供 了 4 种 处 理 方 式 ， 如 表 


6-1 所 示 O 


表 6-1 插入 和 移 除 操作 的 4 中 处 理 方式 


方法 / 处 理 方式 超时 退出 
插入 方法 offer (e, time, unit) 
检查 方法 不 可 用 





` 抛 出 异常 : 当 队 列 满 时 ， 如 果 再 往 队 列 里 播 入 元 素 ， 会 抛 出 


TllegalStateException ("Queue full") 异常 。 当 队列 空 时 ， 从 队列 里 获取 元 
素 会 抛 出 NoSuchElementException 异 常 。 


. 返回 特殊 值 : 当 往 队列 播 入 元 素 时 ， 会 返回 元 素 是 否 播 入 成 功 ， 
成 功 返回 true。 如 果 是 移 除 方法 ， 则 是 从 队列 里 取出 一 个 元 素 ， 如 果 没 


有 则 返回 null。 


` 一 直 阻 塞 : 当 阻 塞 队列 满 时 ， 如 果 生 产 者 线程 往 队 列 里 put 元 
素 ， 队 列 会 一 直 阻 塞 生产 者 线程 ， 直 到 队列 可 用 或 者 响应 中 断 退 出 。 当 
队列 空 时 ， 如 果 消 费 者 线程 从 队列 里 take 元 素 ， 队 列 会 阻塞 住 消费 者 线 
程 ， 直 到 队列 不 为 空 。 


` 超时 退出 : 当 阻 塞 队 列 满 时 ， 如 果 生 产 者 线程 往 队 列 里 播 入 元 
素 ， 队 列 会 阻塞 生产 者 线程 一 段 时 间 ， 如 果 超 过 了 指定 的 时 间 ， 生 产 者 
线程 就 会 退出 。 


这 两 个 附加 操作 的 4 种 处 理 方式 不 方便 记忆 ， 所 以 我 找 了 一 下 这 几 
个 方法 的 规律 。put 和 take 分 别 尾 首 含 有 字母 t，offer 和 poll 都 含有 字母 


Oo 


© 注意 如 果 是 无 界 阻 塞 队 列 ， 队 列 不 可 能 会 出 现 满 的 情况 ， 所 
以 使 用 put 或 offet 方 法 永远 不 会 被 阻塞 ， 而 且 使 用 offet 方 法 时 ， 该 方法 永 


远 返 区 trueo 


6.3.2 Java 里 的 阻塞 队列 


JDK 7 提供 了 7 个 阻塞 队列 ， 如 下 。 
ArrayBlockingQueue: 一 个 由 数组 结构 组 成 的 有 界 阻塞 队列 。 
` LinkedBlockingQueue: 一 个 由 链表 结构 组 成 的 有 界 阻 塞 队列 。 
PriotityBlockingQueue: 一 个 支持 优先 级 排序 的 无 界 阻 塞 队列 。 
. DelayQueue: 一 个 使 用 优先 级 队列 实现 的 无 界 阻塞 队列 。 

. SynchronousQueue: 一 个 不 存储 元 素 的 阻塞 队列 。 

` LinkedTransferQueue: 一 个 由 链表 结构 组 成 的 无 界 阻塞 队列 。 
` LinkedBlockingDeque: 一 个 由 链表 结构 组 成 的 双向 阻塞 队列 。 


1.ArrayBlockingQueue 


ArrayBlockingQueue 是 一 个 用 数组 实现 的 有 界 阻 塞 队 列 。 此 队列 按 
照 先进 先 出 (FIFO〉 的 原则 对 元 素 进行 排序 。 





默认 情况 下 不 保证 线程 公平 的 访问 队列 ， 所 谓 公平 访问 队列 是 指 阻 
徐 的 线程 ， 可 以 按照 阻 紧 的 先后 顺序 访问 队列 ， 即 先 阻 窗 线程 先 访 问 队 





列 。 非 公平 性 是 对 先 等 待 的 线程 是 非 公平 的 ， 当 队列 可 用 时 ， 阻 窗 的 线 
程 都 可 以 争 和 于 访问 队列 的 资格 ， 有 可 能 先 阻 赛 的 线程 最 后 才 访 问 队列 。 
为 了 保证 公平 性 ， 通 常会 降低 否 吐 量 。 我 们 可 以 使 用 以 下 代码 创建 一 个 
公平 的 阻 竖 队列 。 





ArrayBlockingQueue fairQueue = new ArrayBlockingQueue(1000, true); 





访问 者 的 公平 性 是 使 用 可 重 入 锁 实现 的 ， 代 码 如 下 。 





public ArrayBlockingQueue(int capacity, boolean fair) { 
if (capacity <= 0) 
throw new IllegalArgumentException(); 
this.items = new Object[capacity]; 
lock = new ReentrantLock(fair); 
notEmpty = lock.newCondition(); 
notFull = lock.newCondition(); 





2.LinkedBlockingQueue 


LinkedBlockingQueue 是 一 个 用 链表 实现 的 有 界 阻 团队 列 。 此 队列 的 
默认 和 最 大 长 度 为 Integer.MAX_VALUE。 此 队列 按照 先进 先 出 的 原则 
对 元 素 进行 排序 。 





3.PriorityBlockingQueue 


PriorityBlockingQueue 是 一 个 文 持 优先 级 的 无 界 阻 罕 队 列 。 上 默认 情 
况 下 元 素 采 取 自 然 顺 序 升 序 排列 。 也 可 以 自 定 义 类 实现 compareTo() 方 








法 来 指定 元 素 排序 规则 ， 或 者 初始 化 PriorityBlockingQueue 时 ， 指 定 构 
造 参 数 Comparator 来 对 元 素 进 行 排序 。 需 要 注意 的 是 不 能 保证 同 优 先 级 
元 素 的 顺序 。 











4.DelayQueue 


DelayQueue 是 一 个 文 持 延 时 获取 元 素 的 无 界 阻塞 队列 。 队 列 使 用 
PriorityQueue 来 实现 。 队 列 中 的 元 素 必须 实现 Delayed 接 口 ， 在 创建 元 系 
时 可 以 指定 多 和 久 才 能 从 队列 中 获取 当前 元 素 。 只 有 在 延迟 期 满 时 才能 从 
队列 中 提取 元 系 。 


DelayQueue 非 常 有 用 ， 可 以 将 DelayQueue 运 用 在 以 下 应 用 场景 。 


` 缓存 系统 的 设计 : 可 以 用 DelayQueue 保 存 缓存 元 素 的 有 效 期 ， 使 
用 一 个 线程 循环 查询 DelayQueue， 一 旦 能 从 DelayQueue 中 获取 元 素 时 ， 
表示 缓存 有 效 期 到 了 。 


. 定时 任务 调度 : 使 用 DelayQueue 保 存 当 天 将 会 执行 的 任务 和 执行 
时 间 ， 一 旦 从 DelayQueue 中 获取 到 任务 就 开始 执行 ， 比 如 TimerQueue 就 


是 使 用 DelayQueue 实 现 的 。 
(1) 如 何 实现 Delayed 接 口 


DelayQueue 队 列 的 元 素 必须 实现 Delayed 接 口 。 我 们 可 以 参考 


ScheduledThreadPoolExecutor 里 ScheduledFutureTask 关 的 实现 ， 一 共有 三 
步 。 


第 一 步 : 在 对 象 创 建 的 时 候 ， 初 始 化 基本 数据 。 使 用 time 记 录 当 前 
对 象 延迟 到 什么 时 候 可 以 使 用 ， 使 用 sequenceNumber 来 标识 元 素 在 队列 
中 的 先后 顺序 。 人 代码 如 下 。 








private static final AtomicLong sequencer = new AtomicLong(0) 
ScheduledFutureTask(Runnable r, V result, long ns, long period) { 
ScheduledFutureTask(Runnable r, V result, long ns, long period) { 

super(r, result),; 

this.time = ns; 

this.period = period; 

this.sequenceNumber = sequencer.getAndIncrement(); 





第 二 步 : 实现 getDelay 方 法 ， 该 方法 返回 当前 元 素 还 需要 延 时 多 长 
时 间 ， 单 位 是 纳 秒 ， 代 码 如 下 。 





public long getDelay(TimeUnit unit) { 
return unit.convert(time - now(), TimeUnit.NANOSECONDS); 
} 





过 构造 函数 可 以 看 出 延迟 时 间 参 数 ns 的 单位 是 纳 秒 ， 上 自己 设计 的 
时 候 最 好 使 用 纳 秒 ， 因 为 实现 getDelay0 方 法 时 可 以 指定 任意 单位 ， 一 
旦 以 秒 或 分 作为 单位 ， 而 延 时 时 间 又 精确 不 到 纳 秒 就 乒 燃 了 。 使 用 时 请 
注意 当 time 小 于 当前 时 间 时 ，getDelay 会 返回 负数 。 


第 三 步 : 实现 compareTo 方 法 来 指定 元 素 的 顺序 。 例 如 ， 让 延 时 时 
间 最 长 的 放 在 队列 的 末尾 。 实 现代 人 码 如 下 。 


[Ee | 


public int compareTo(Delayed other) { 
if (other == this) // compare zero ONLY if same object 
return 9; 
if (other instanceof ScheduledFutureTask) { 
ScheduledFutureTask<> x = (ScheduledFutureTask<>)other; 
long diff = time - x.time; 
if (diff < 0) 
return -1; 
else if (diff > 0) 
return 1; 
else if (sequenceNumber < x.sequenceNumber) 
return -1; 
else 
return 1; 


long d = (getDelay(TimeUnit.NANOSECONDS) - 
other .getDelay(TimeUnit .NANOSECONDS ) ) ， 
return (d == 0) 0 : ((d<0) -1 : 1); 





(2) 如 何 实现 延 时 阻塞 队列 


延 时 阻塞 队列 的 实现 很 简单 ， 当 消费 者 从 队列 里 获取 元 素 时 ， 如 宋 
元 素 没 有 达到 延 时 时 间 ， 就 阻塞 当前 线程 。 





long delay = first,.getDelay(TimeUnit ,NANOSECONDS ) ; 
if (delay <= 0) 

return q.poll(); 
else if (leader != null) 

available.await(); 

else { 

Thread thisThread = Thread.currentThread(); 
leader = thisThread; 


try { 
available.awaitNanos(delay); 
} finally { 
if (leader == thisThread) 
leader = null; 





代码 中 的 变量 leader 是 一 个 等 竺 获取 队列 头 部 元 素 的 线程 。 如 果 
leader 不 等 于 空 ， 表 示 已 经 有 线程 在 等 待 获取 队列 的 头 元 素 。 所 以 ， 使 
用 await(0) 方 法 让 当前 线程 等 竺 信号。 如 果 leader 等 于 空 ， 则 把 当前 线程 














设置 成 leader， 并 使 用 awaitNanos() 方 法 让 当前 线程 等 竺 接收 信号 或 等 待 
delay 时 间 。 


5.SynchronousQueue 


SynchronousQueue 是 一 个 不 存储 元 素 的 阻塞 队列 。 每 一 个 put 操 作 必 


须 等 待 一 个 take 操 作 ， 否 则 不 能 继续 添加 元 素 。 


它 文 持 公平 访问 队列 。 默 认 情 况 下 线程 采用 非 公 平 性 策略 访问 队 
列 。 使 用 以 下 构造 方法 可 以 创建 公平 性 访问 的 SynchronousQueue， 如 果 
设置 为 tue， 则 等 待 的 线程 会 采用 先进 先 出 的 顺序 访问 队列 。 





public SynchronousQueue(boolean fair) { 
transferer = fair new TransferQueue() : new TransferStack() ， 
} 





SynchronousQueue 可 以 看 成 是 一 个 传 球 手 ， 负 员 把 生产 者 线程 处 理 
的 数据 直接 传递 给 消费 者 线程 。 队 列 本 号 并 不 存储 任何 元 素 ， 非 常 适合 
传递 性 场景 。SynchronousQueue 的 吞吐 量 高 于 LinkedBlockingQueue 和 


ArayBlockingQueue。 
6.LinkedTransferQueue 


LinkedTransferQueue 是 一 个 由 链表 结构 组 成 的 无 界 阻塞 
TransferQueue 队 列 。 相 对 于 其 他 阻塞 队列 ，LinkedTransferQueue 多 了 


tryTransfer 和 transfer 方 法 。 


(1) transfer 方 法 





如 果 当 前 有 消费 者 正在 等 待 接收 元 素 〈 消 费 者 使 用 take0 方 法 或 带 
时 间 限 制 的 poll0 方 法 时 ) ，transfer 方 法 可 以 把 生产 者 传 入 的 元 素 立 刻 
transfer〈 传 输 ) 给 消费 者 。 如 果 没 有 消费 者 在 等 待 接收 元 素 ，transfer 方 
法 会 将 元 素 存 放 在 队列 的 tail 节 点 ， 并 等 到 该 元 素 被 消费 者 消费 了 才 返 
回 。transfer 方 法 的 关键 代码 如 下 。 








Node pred = tryAppend(s, haveData); 
return awaitMatch(s, pred, e, (how == TIMED), nanos); 











一 行 代码 是 试图 把 存放 当前 元 素 的 s 节 点 作为 ta 节点 。 第 二 行 代 
码 是 让 CPU 上 自 旋 等 待 消费 者 消费 元 素 。 因 为 自 旋 会 消耗 CPU， 上 所 以 上 自 旋 
一 定 的 次 数 后 使 用 Thread.yield() 方 法 来 暂停 当前 正在 执行 的 线程 ， 并 执 
行 其 他 线程 。 











(2) tryTransfer 方 法 


tryTransfer 方 法 是 用 来 试探 生产 者 传 入 的 元 素 是 否 能 直接 传 给 消费 
者 。 如 果 没 有 消费 者 等 待 接 收 元 素 ， 则 返回 false。 和 transfer 方 法 的 区 别 
是 tryTransfer 方 法 无 论 消 费 者 是 否 接收 ， 方 法 立即 返回 ， 而 transfer 方 法 
是 必须 等 到 消费 者 消费 了 才 返 回 














对 于 带 有 时 间 限 制 的 tryTransfer (Ee，long timeout，TimeUnit 
unit) 方法 ， 试 图 把 生产 者 传 入 的 元 素 直 接 传 给 消费 者 ， 但 是 如 果 没 有 
消费 者 消费 该 元 素 则 等 待 指定 的 时 间 再 返回 ， 如 果 超 时 还 没 消费 元 素 ， 
则 返回 false， 如 果 在 超时 时 间 内 消费 了 元 素 ， 则 返回 true。 








7.LinkedBlockingDeque 


LinkedBlockingDeque 是 一 个 由 链表 结构 组 成 的 双向 阻塞 队列 。 所 请 
双向 队列 指 的 是 可 以 从 队列 的 两 端 插 入 和 移出 元 素 。 双 疝 队 列 因 为 多 了 
一 个 操作 队列 的 入 口 ， 在 多 线程 同时 入 队 时 ， 也 就 减少 了 一 半 的 竞争 。 
相 比 其 他 的 阻塞 队列 ，LinkedBlockingDeque 多 了 addFirst、addLast、 
offerFirst、offerLast、peekFirst 和 peekLast 等 方法 ， 以 First 单 词 结尾 的 方 
法 ， 表 示 插 入 、 获 取 〈peek) 或 移 除 双 端 队列 的 第 一 个 元 了 水 。 以 Last 单 
词 结尾 的 方法 ， 表 示 插 入 、 获 取 或 移 除 双 端 队列 的 最 后 一 个 元 素 。 另 
外 ， 插 入 方法 add 等 同 于 addLast， 移 除 方法 remove 等 效 于 removeFirst。 
但 是 take 方 法 却 等 同 于 takeFirst， 不 知道 是 不 是 JDK 的 bug， 使 用 时 还 是 
用 带 有 First 和 Last 后 级 的 方法 更 清楚 。 


在 初始 化 LinkedBlockingDeque 时 可 以 设置 容量 防止 其 过 度 膨胀 。 另 
外 ， 双 向 阻塞 队列 可 以 运用 在 “工作 窃取 ”模式 中 。 





6.3.3 ”阻塞 队列 的 实现 原理 


如 果 队 列 是 空 的 ， 消 费 者 会 一 直 等 待 ， 当 生产 者 添加 元 素 时 ， 消 费 
者 是 如 何 知 道 当 前 队列 有 元 素 的 呢 ? 如 果 让 你 来 设计 阻塞 队列 你 会 如 何 
设计 ， 如 何 让 生产 者 和 消费 者 进行 高 效率 的 通信 呢 ? 让 我 们 先 来 看 看 
JDK 是 如 何 实现 的 。 





使 用 通知 模式 实现 。 所 谓 通知 模式 ， 就 是 当 生 产 者 往 满 的 队列 里 
添加 元 素 时 会 阻塞 住 生产 者 ， 当 消费 者 消费 了 一 个 队列 中 的 元 素 后 ， 会 
通知 生产 者 当前 队列 可 用 。 通 过 查看 JDK 源 码 发 现 ArrayBlockingQueue 
使 用 了 Condition 来 实现 ， 代 码 如 下 。 








private final Condition notFull; 

private final Condition notEmpty; 

public ArrayBlockingQueue(int capacity, boolean fair) { 
// 省 上 略 其 他 代码 
notEmpty = lock.newCondition(); 
notFull = lock.newCondition(); 




















} 
public void put(E e) throws InterruptedException { 
checkNotNull(e); 
final ReentrantLock lock = this.lock; 
lock.lockIinterruptibly(); 


try { 
while (count == items.length) 
notFull.await( ); 
insert(e); 
} finally { 


lock.unlock(); 
} 


public E take() throws InterruptedException { 
final ReentrantLock lock = this.lock; 
lock.lockIinterruptibly(); 
try { 
while (count == 0) 
notEmpty .await( ); 
return extract(); 


} finally { 
lock.unlock(); 
} 
} 


private void insert(E x) { 
Items[putIndex] = x; 
putIndex = inc(putIndex); 
++COoUuNt,; 
notEmpty.signal(); 





当 往 队列 里 插入 一 个 元 素 时 ， 如 果 队 列 不 可 用 ， 那 么 阻塞 生产 者 主 
要 通过 LockSupport.park (this) 来 实现 。 





public final void await() throws InterruptedException { 
if (Thread,.interrupted()) 
throw new InterruptedException(); 
Node node = addConditionwaiter(); 
int SavedState = fullyRelease(node); 
int interruptMode = 0; 
while (!isOnSyncQueue(node)) { 
LockSupport.park(this); 
if ((interruptMode = checkIinterruptwhilewaiting(node)) != 0) 
break; 


if (acquireQueued(node, savedState) && interruptMode != THROW_IE) 
interruptMode = REINTERRUPT,; 

if (node.nextwaiter != null) // clean up if cancelled 
unlinkCancelledwaiters(); 

if (interruptMode != 0) 
reportIinterruptAfterwait(interruptMode); 





继续 进入 源码 ， 发 现 调 用 setBlocker 先 保存 一 下 将 要 阻塞 的 线程 ， 
然后 调用 unsafe.park 阻 塞 当前 线程 。 





public static void park(Object blocker) { 
Thread t = Thread,.currentThread(); 
setBlocker(t, blocker); 
unsafe.park(false, OL); 
setBlocker(t, null); 





unsafe.park 是 个 native 方 法 ， 代 码 如 下 。 





public native void park(boolean isAbsolute, long time); 





park 这 个 方法 会 阻 豆 当前 线程 ， 只 有 以 下 4 种 情况 中 的 一 种 发 生 
时 ， 该 方法 才 会 返回 。 


与 pa 永 对 应 的 unpatrk 执 行 或 已 经 执行 时 。 “已 经 执行 ”是 指 unpark 
先 执 行 》 然后 再 执行 pafk 的 情况 o 


线程 被 中 断 时 。 


` 异常 现象 发 生 时 ， 这 个 异常 现象 没有 任何 原因 。 


继续 看 一 下 VM 是 如 何 实现 park 方 法 : park 在 不 同 的 操作 系统 中 使 
用 不 同 的 方式 实现 ， 在 Linux 下 使 用 的 是 系统 方法 pthread_cond_wait 实 
现 。 实 现代 码 在 JVM 源 码 路 径 src/os/linux/vm/os_linux.cpp 里 的 





os::PlatformEvent::park 方 法 ， 代 人 码 如 下 。 





void os::PJatformEvent: :park() { 
int V 
for (;;) { 
Vv = _Event ; 
if (Atomic: :cmpxchg (v-1, & Event, v) == V) break ， 


guarantee (v >= 0, "invariant") ， 

if (v == 0) { 

// Do this the hard way by blocking ... 

int status = pthread mutex_lock(_mutex); 
assert_status(status == 0, status, "mutex_lock"); 
guarantee (_nParked == 0, "invariant") ， 

++ _nParked ， 

while (_Event < 0) { 

status = pthread cond wait(_cond, _mutex); 





// for some reason, under 2.7 lwp_cond wait() may return ETIME ... 
// Treat this the same as if the wait was interrupted 

If (status == ETIME) { status = EINTR; } 

assert_status(status == 0 || status == EINTR, status, "cond wait"); 


-- _nNnParked ，; 
// In theory we could move the ST of © into _Event past the unlock(), 
// but then we'd need a MEMBAR after the ST. 


_Event = 0,， 
status = pthread mutex_unlock(_mutex); 
assert_status(status == 0, status, "mutex_unlock"); 


guarantee (_Event >= 0, "invariant") ， 


} 








0 数 ，cond 是 condition 
的 缩写 ， 字 面 意思 可 以 理解 为 线程 在 等 待 一 个 条 件 发 生 ， 这 个 条 件 是 一 
个 全 局 变量 。 这 个 方法 接收 两 个 参数 ， 一 个 共享 变量 cond， 一 个 互 斥 
量 mutex。 而 unpark 方 法 在 Linux 下 是 使 用 pthread_cond_signal 实 现 的 。 





park 方 法 在 Windows 下 则 是 使 用 WaitForSingleObject 实 现 的 。 想 知道 
pthread_cond_wait 是 如 何 实现 的 ， 可 以 参考 glibc-2.5 的 


nptl/sysdeps/pthread/pthread_cond_wait.c。 


当 线 程 被 阻塞 队列 阻塞 时 ， 线 程 会 进入 WAITING (parking) 状 
我 们 可 以 使 用 jstack dump 阻 塞 的 生产 者 线程 看 到 这 点 ， 如 下 。 








"main" prio=5 tid=0x00007fc83c000000 nid=0x10164e000 waiting on condition [9x000000( 
java.1lang.Thread.State: WAITING (parking ) 

at sun.misc.Unsafe.park(Native Method ) 
- parking to wait for <0x0000000140559fe8> (a java.util.concurrent.1c 
AbstractQueuedSynchronizer$ConditionObject) 
at java.util,.concurrent.locks.LockSupport.park(LockSupport.java:186) 
at java.util,.concurrent.locks.AbstractQueuedSynchronizer$ConditionObje 
await(AbstractQueuedSynchronizer .java:2043) 
at java.util,.concurrent.ArrayBlockingQueue.put(ArrayBlockingQueue .jave 
at blockingqueue.ArrayBlockingQueueTest.main(ArrayBlockingQueueTest .jt 


ee | 


6.4 ”Fork/Join 框 架 


本 节 将 会 介绍 Fork/Join 框 架 的 基本 原理 、 算 法 、 设 计 方式 、 应 用 与 


实现 等 。 


6.4.1 ”什么 是 Fork/Join 框 架 


Fork/Join 框 架 是 Java 7 提供 的 一 个 用 于 并 行 执行 任务 的 框架 ， 是 一 
个 把 大 任务 分 割 成 若干 个 小 任务 ， 最 终 汇 总 每 个 小 任务 结果 后 得 到 大 任 


务 结果 的 框架 。 


我 们 再 通过 Fork 和 Join 这 两 个 单词 来 理解 一 下 Fork/Join 框 架 。Fork 
就 是 把 一 个 大 任务 切 分 为 若干 子 任务 并 行 的 执行 ，Join 就 是 合并 这 些 子 
任务 的 执行 结果 ， 最 后 得 到 这 个 大 任务 的 结果 。 比 如 计算 1+2+.… 
+10000， 可 以 分 割 成 10 个 子 任务 ， 每 个 子 任务 分 别 对 1000 个 数 进行 求 
和 ， 最 终 汇 总 这 10 个 子 任务 的 结果 。Fork/Join 的 运行 流程 如 图 6-6 所 示 。 








子 任务 1.1 子 任务 1. 


大 任务 结果 





图 6-6 ”Fork Join 的 运行 流程 图 


6.4.2 ”工作 窃取 算法 


工作 贸 取 〈workrstealing) 算法 是 指 茶 个 线程 从 其 他 队列 里 禄 取 任 
务 来 执行 。 那 么 ， 为 什么 需要 使 用 工作 禄 取 算 法 呢 ? 假如 我 们 需要 做 一 
个 比较 大 的 任务 ， 可 以 把 这 个 任务 分 割 为 春 干 互 不 依赖 的 子 任务 ， 为 了 
减少 线程 间 的 竞争 ， 把 这 些 子 任务 分 别 放 到 不 同 的 队列 里 ， 并 为 每 个 队 
列 创建 一 个 单独 的 线程 来 执行 队列 里 的 任务 ， 线 程 和 队列 一 一 对 应 。 比 
如 A 线程 负责 处 理 A 队 列 里 的 任务 。 但 是 ， 有 的 线程 会 先 把 自己 队列 里 
的 任务 干 完 ， 而 其 他 线程 对 应 的 队列 里 还 有 任务 等 得 处 理 。 干 完 活 的 线 
程 与 其 等 着 ， 不 如 去 帮 其 他 线程 干 活 ， 于 是 它 就 去 其 他 线程 的 队列 里 寡 
取 一 个 任务 来 执行 。 而 在 这 时 它们 会 访问 同一 个 队列 ， 所 以 为 了 减少 贸 
取 任 务 线程 和 被 鳃 取 任 务 线程 之 间 的 莞 争 ， 通 常会 使 用 双 端 队列 ， 被 箔 
取 任 务 线程 永远 从 双 端 队列 的 头 部 拿 任务 执行 ， 而 禄 取 任 务 的 线程 永远 
从 双 端 队列 的 尾部 拿 任务 执行 。 





工作 人 贸 取 的 运行 流程 如 图 6-7 所 未 。 





图 6-7 工作 窃取 运行 流程 图 


工作 狠 取 算法 的 优点 : 充分 利用 线程 进行 并 行 计 算 ， 减 少 了 线程 
间 的 竞争 。 
工作 饭 取 算法 的 缺点 : 在 某 些 情况 下 还 是 存在 竞争 ， 比 如 双 端 队 


列 里 只 有 一 个 任务 时 。 并 且 该 算法 会 消耗 了 更 多 的 系统 资源 ， 比 如 创建 
多 个 线程 和 多 个 双 端 队列 。 


6.4.3 ”Fork/Join 框 架 的 设计 


我 们 已 经 很 清楚 Fork/Join 框 架 的 需求 了 ， 那 么 可 以 思考 一 下 ， 如 果 
让 我 们 来 设计 一 个 Fork/Join 框 架 ， 该 如 何 设计 ? 这 个 思考 有 助 于 你 理解 
Fork/Join 框 架 的 设计 。 


步骤 1 分 割 任 务 。 首 先 我 们 需要 有 一 个 fork 类 来 把 大 任务 分 割 成 
子 任务 ， 有 可 能 子 任务 还 是 很 大 ， 所 以 还 需要 不 售 地 分 割 ， 直 到 分 割 出 
的 子 任务 足够 小 。 


步骤 2 执行 任务 并 合并 结果 。 分 割 的 子 任务 分 别 放 在 双 端 队列 
里 ， 然 后 几 个 局 动 线程 分 别 从 双 端 队列 里 获取 任务 执行 。 子 任务 执行 完 
的 结果 都 统一 放 在 一 个 队列 里 ， 局 动 一 个 线程 从 队列 里 拿 数据 ， 然 后 合 
并 这 些 数据 。 


Fork/Join 使 用 两 个 类 来 完成 以 上 两 件 事 情 。 
(DForkJoinTask: 我 们 要 使 用 ForkJoin 框 架 ， 必 须 首 先 创 建 一 个 
ForkJoin 任 务 。 它 提供 在 任务 中 执行 fork() 和 join() 操 作 的 机 制 。 通 常情 况 


下 ， 我 们 不 需要 直接 继承 ForkJoinTask 类 ， 只 需要 继承 它 的 子 类 ， 
Fork/Join 框 染 提供 了 以 下 两 个 子 类 。 





. RecursiveAction: 用 于 没有 返回 结果 的 任务 。 


. RecursiveTask: 用 于 有 和 返回 结果 的 任务 。 


(OForkJoinPool: ForkJoinTask 需 要 通过 ForkJoinPool 来 执行 。 


任务 分 割 出 的 子 任务 会 添加 到 当前 工作 线程 所 维护 的 双 端 队列 中 ， 
进入 队列 的 头 部 。 当 一 个 工作 线程 的 队列 里 和 暂时 没有 任务 时 ， 它 会 随机 
从 其 他 工作 线程 的 队列 的 尾部 获取 一 个 任务 。 


6.4.4 ”使 用 Fork/Join 杠 架 


让 我 们 通过 一 个 简单 的 需求 来 使 用 Fork/Join 框 架 ， 需 求 是 :计算 
1+2+3+4 的 结 


使 用 Fork/Join 框 染 首 先 要 考虑 到 的 是 如 何 分 割 任 务 ， 如 果 和 希望 每 个 
子 任务 最 多 执行 两 个 数 的 相 加 ， 那 么 我 们 设置 分 割 的 立 值 是 2， 由 于 是 4 
个 数字 相 加 ， 所 以 Fork/Join 框 架 会 把 这 个 任务 fork 成 两 个 子 任务 ， 子 任 
务 一 负责 计算 1+2， 子 任务 二 负责 计算 3+4， 然 后 再 join 两 个 子 任务 的 结 
果 。 因 为 是 有 结果 的 任务 ， 所 以 必须 继承 RecursiveTask， 实 现代 码 如 
hs 








package fj; 
import java.util.concurrent.ExecutionException,; 
import java.util.concurrent.ForkJoinPool; 
import java.util.concurrent.Future,; 
import java.util.concurrent.RecursiveTask; 
public class CountTask extends RecursiveTask<Integer> { 
private static final int THRESHOLD = 2; // 阅 值 
private int Start 
private int end; 
public CountTask(int start, int end) { 
this.start = start,; 
this.end = end; 


@Override 
protected Integer compute() { 
int Sum = 0; 
// 如 果 任 务 足 够 小 就 计算 任务 
boolean canCompute = (end - start) <= THRESHOLD; 
If (canCompute) { 
for (int i = start; i <= end; i++) { 
Sum += i; 











} 
} else { 
// 如 果 任 务 大 于 闵 值 ， 就 分 裂 成 两 个 子 任务 计算 
int middle = (start + end) / 2; 
CountTask leftTask = new CountTask(start, middle); 








CountTask rightTask = new CountTask(middle + 1, end); 
// 执行 子 任务 

leftTask.fork(); 
rightTask.fork(); 

// 等 待 子 任务 执行 完 ， 并 得 到 其 结果 
int leftResult=leftTask.join(); 
int rightResult=rightTask.join(); 
// 合并 子 任务 

sum = leftResult + rightResult; 


























return sum; 


public static void main(String[] args) { 
ForkJoinPool forkJoinPool = new ForkJoinPool(); 
// 生成 一 个 计算 任务 ， 负 责 计算 1+2+3+4 
CountTask task = new CountTask(1, 4); 
// 执行 一 个 任务 
Future<Integer> result = forkJoinPool.submit(task); 
try { 





System,.out.println(result.get()); 
} catch (InterruptedException e) { 
} catch (ExecutionException e) { 





通过 这 个 例子 ， 我 们 进一步 了 解 ForkJoinTask，ForkJoinTask 与 一 般 
任务 的 主要 区 别 在 于 它 需 要 实现 compute 方 法 ， 在 这 个 方法 里 ， 首 先 需 
要 判断 任务 是 否 足 够 小 ， 如 果 足 够 小 就 直接 执行 任务 。 如 果 不 足 够 小 ， 
就 必须 分 割 成 两 个 子 任 务 ， 每 个 子 任务 在 调用 fork 方 法 时 ， 又 会 进入 
compnute 方 法 ， 看 看 当前 子 任务 是 否 需要 继续 分 割 成 子 任务 ， 如 果 不 需 
要 继续 分 市， 则 执行 当前 子 任务 并 返回 结果 。 使 用 join 方 法 会 等 待 子 任 
务 执行 完 并 得 到 其 结果 。 




















6.4.5 “Fork/Join 框 架 的 异常 处 理 


ForkJoinTask 在 执行 的 时 候 可 能 会 抛 出 异常 ， 但 是 我 们 没 办 法 在 主 
线程 里 直接 捕获 异常 ， 所 以 ForkJoinTask 提 供 了 isCompletedAbnormally( 
方法 来 检查 任务 是 人 否 已 经 抛 出 弄 常 或 已 经 锐 取 消 了 ， 并 且 可 以 通过 
ForkJoinTask 的 getException 方 法 获取 异常 。 使 用 如 下 代码 。 











if(task.isCcompletedAbnormally()) 
{ 


System,.out.println(task.getException()); 





回 
回 


Bi 


getException 方 法 返回 Throwable 对 象 ， 如 果 任 务 被 取消 了 则 i 
CancellationException。 如 果 任 务 没有 完成 或 者 没有 抛 出 异常 则 i 


Bi 


null 。 


6.4.6 ”Fork/Join 框 架 的 实现 原理 


ForkJoinPool 由 ForkJoinTask 数 组 和 ForkJoinWorkerThread 数 组 组 
成 ，ForkJoinTask 数 组 负责 将 存放 程序 提交 给 ForkJoinPool 的 任务 ， 而 


ForkJoinWorkerThread 数 组 人 负责 执行 这 些 任务 。 
(1) ForkJoinTask 的 fork 方 法 实现 原理 


当 我 们 调用 ForkJoinTask 的 fork 方 法 时 ， 程 序 会 调用 
ForkJoinWorkerThread 的 pushTask 方 法 异步 地 执行 这 个 任务 ， 然 后 立即 
返回 结果 。 代 码 如 下 。 





public final ForkJoinTask<V> fork() { 
((ForkJoinworkerThread) Thread.currentThread()) 
.pushTask(this); 
return this; 





pushTask 方 法 把 当前 任务 存放 在 ForkJoinTask 数 组 队列 里 。 然 后 再 
调用 ForkJoinPool 的 signalWork() 方 法 唤醒 或 创建 一 个 工作 线程 来 执行 任 
务 。 代 码 如 下 。 





final void pushTask(ForkJoinTask<> t) { 

ForkJoinTask<>[] q; int s, m; 

if ((q = queue) != null) { // ignore if queue removed 
long u = (((s = queueTop) & (m = q.length - 1)) << ASHIFT) + ABASE; 
UNSAFE .putOrderedobject(q, u, t); 
queueTop = S + 1; // or use putorderedInt 
if ((s -= queueBase) <= 2) 

pool.signalwork(); 

else if (s == m) 


growQueue( ); 





(2) ForkJoinTask 的 join 方 法 实现 原理 


Join 方 法 的 主要 作用 是 阻塞 当前 线程 并 等 得 获取 结果 。 让 我 们 一 起 
看 看 ForkJoinTask 的 join 方 法 的 实现 ， 代 码 如 下 。 





public final V join() { 
if (doJoin() != NORMAL) 
return reportResult(); 
else 
return getRawResult(); 


private V reportResult() { 
int s; Throwable ex; 
if ((s = status) == CANCELLED) 
throw new CancellationException(); 
If (Ss == EXCEPTIONAL && (ex = getThrowableException()) != null) 
UNSAFE. throwException(ex); 
return getRawResult(); 





首先 ， 它 调用 了 doJoin0 方 法 ， 通 过 doJoin() 方 法 得 到 当前 任务 的 状 
态 来 判断 返回 什么 结果 ， 任 务 状态 有 4 种 : 已 完成 (NORMAL) 、 被 取 
消 CCANCELLED) 、 信 号 (SIGNAL ) 和 出 现 异 常 
(EXCEPTIONAL) 。 


如 果 任 务 状态 是 已 完成 ， 则 直接 返回 任务 结果 。 
如 果 任 务 状态 是 被 取消 ， 则 直接 抛 出 CancellationException 。 


. 如 果 任 务 状 态 是 抛 出 异常 ， 则 直接 抛 出 对 应 的 异常 。 


让 我 们 再 来 分 析 一 下 doJoin() 方 法 的 实现 代码 。 





private int doJoin() { 
Thread t; ForkJoinworkerThread w; int s; boolean completed; 
if ((t = Thread,currentThread()) instanceof ForkJoinworkerThread) { 
if ((s = status) < 0) 
return s; 
if ((w = (ForkJoinworkerThread)t).unpushTask(this)) { 
try { 
completed = exec(); 
} catch (Throwable rex) { 
return setExceptionalCompletion(rex); 


} 
if (completed) 
return setCcompletion(NORMAL ); 


return w.joinTask(this); 


else 
return externalAwaitDone( ); 





在 doJoin() 方 法 里 ， 首 移 通 过 得 看 任务 的 状态 ， 看 任务 是 否 已 经 执 
行 完 成 ， 如 果 执 行 完成 ， 则 直接 返回 任务 状态 ， 如果 没 有 执行 完 ， 则 从 
任务 数组 里 取出 任务 并 执行 。 如 果 任 务 顺利 执行 完成 ， 则 设置 任务 状态 
为 NORMAL， 如 果 出 现 异常 ， 则 记录 异常 ， 并 将 任务 状态 设置 为 
EXCEPTIONAL。 


6.5 ”本章 小 结 


本 章 介 绍 了 Java 中 提供 的 各 种 并 发 容器 和 框架 ， 并 分 析 了 该 容器 和 
框架 的 实现 原理 ， 从 中 我 们 能 够 领略 到 大 师 级 的 设计 思路 ， 和 希望 读者 能 
够 充分 理解 这 种 设计 思想 ， 并 在 以 后 开发 的 并 及 程序 时 ， 运 用 上 这 些 并 
发 编程 的 技巧 。 


第 7 章 Java 中 的 13 个 原子 操作 类 





当 程 序 更 新 一 个 变量 时 ， 如 果 多 线程 同时 更 新 这 个 变量 ， 可 能 得 到 
期 望 之 外 的 值 ， 比 如 变量 i=1，A 线 程 更 新 it+1，B 线 程 也 更 新 i+t1， 经 过 
两 个 线程 操作 之 后 可 能 i 不 等 于 3， 而 是 等 于 2。 因 为 A 和 B 线 程 在 更 新 变 
量 i 的 时 候 拿 到 的 都 是 1， 这 就 是 线程 不 安全 的 更 新 操作 ， 通 常 我 们 会 使 
用 synchronized 来 解决 这 个 问题 ，synchronized 会 保证 多 线程 不 会 同时 更 
新 变量 i。 











而 Java 从 JDK 1.5 开 始 提 供 了 java.util.concurrent.atomic 包 【以 下 简称 
Atomic 包 ) ， 这 个 包 中 的 原子 操作 类 提供 了 一 种 用 法 简单 、 性 能 高 效 、 
线程 安全 地 更 新 一 个 变量 的 方式 。 


因为 变量 的 类 型 有 很 多 种 ， 所 以 在 Atomic 包 里 一 共 提 供 了 13 个 类 ， 
属于 4 种 类 型 的 原子 更 新 方式 ， 分 别 是 原子 更 新 基本 类 型 、 原 子 更 新 数 
组 、 原 子 更 新 引用 和 原子 更 新 属性 “字段 ，。Atomic 包 里 的 类 基本 都 是 
使 用 Unsafe 实 现 的 包 闭 类 。 





7.1 原子 更 新 基本 类 型 类 


使 用 原子 的 方式 更 新 基本 类 型 ，Atomic 包 提供 了 以 下 3 个 类 。 
AtomicBoolean: 原子 更 新 布尔 类 型 。 

. AtomicInteger: 原子 更 新 整 型 。 

. AtomicLong: 原子 更 新 长 整 型 。 


以 上 3 个 类 提供 的 方法 几乎 一 模 一 样 ， 所 以 本 节 仅 以 AtomicInteger 
为 例 进行 讲解 ，AtomicInteger 的 常用 方法 如 下 。 


. int addAndGet (int delta) : 以 原子 方式 将 输入 的 数值 与 实例 中 的 
值 (AtomicInteget 里 的 value) 相 加 ， 并 返回 结果 。 


:boolean compareAndSet (int expect，int update) : 如 果 输 入 的 数 
值 等 于 预期 值 ， 则 以 原子 方式 将 该 值 设 置 为 输入 的 值 。 


` int getAndIncrement0: 以 原子 方式 将 当前 值 加 1， 注 意 ， 这 里 返回 
的 是 自 增 前 的 值 。 


. void lazySet (int newValue) : 最 终 会 设置 成 newValue， 使 用 lazySet 
设置 值 后 ， 可 能 导致 其 他 线程 在 之 后 的 一 小 段 时 间 内 还 是 可 以 读 到 旧 的 
值 。 关 于 该 方法 的 更 多 信息 可 以 参考 并 发 编程 网 翻译 的 一 篇 文章 


《AtomicLonglazySet 是 如 何 工 作 的 ? 》， 文 章 地 址 


是 “http:/ /ifeve.com/how-does-atomiclong-lazyset-wotk/ 


` int getAndSet (int newValue) : 以 原子 方式 设置 为 newValue 的 


值 ， 并 返回 旧 值 。 
AtomicInteger 示 例 代 码 如 代码 清单 7-1 所 示 。 


代码 清单 7-1 AtomicIntegerTest.java 





import java.util.concurrent .atomic.AtomicInteger ， 
public class AtomicIntegerTest { 
static AtomicInteger al = new AtomicInteger(1); 
public static void main(String[] args) { 
System.out.printin(ai.getAndIincrement()); 
System.out.printin(ai.get()); 
} 





输出 结果 如 下 。 





Dp 





那么 getAndIncrement 是 如 何 实现 原子 操作 的 呢 ? 让 我 们 一 起 分 析 其 
实现 原理 ，getAndIncrement 的 源码 如 代码 清单 7-2 所 示 。 


代码 清单 7-2 AtomicInteger.java 





public final int getAndIncrement() { 
for (;;) { 
int current = get(); 
int next = current + 1; 


If (compareAndSet(current, next)) 
return current; 


} 


} 
public final boolean compareAndSet(int expect, int update) { 

return unsafe.compareAndSwapInt(this, valueOffset, expect, update); 
} 





源码 中 for 循 环 体 的 第 一 步 先 取 得 AtomicInteger 里 存储 的 数值 ， 第 二 
步 对 AtomicInteger 的 当前 数值 进行 加 1 操作 ， 关 键 的 第 三 步调 用 
compareAndSet 方 法 来 进行 原子 更 新 操作 ， 该 方法 先 检查 当前 数值 是 否 
等 于 current， 等 于 意味 着 AtomicInteger 的 值 没 有 被 其 他 线程 修改 过 ， 则 
将 AtomicInteger 的 当前 数值 更 新 成 next 的 值 ， 如 果 不 等 compareAndSet 方 
法 会 返回 false， 程 序 会 进入 for 循 环 重新 进行 compareAndSet 操 作 。 


Atomic 包 提供 了 3 种 基本 类 型 的 原子 更 新 ， 但 是 Java 的 基本 类 型 里 
还 有 char、float 和 double 等 。 那 么 问题 来 了 ， 如 何 原 子 的 更 新 其 他 的 基 
本 类 型 呢 ? Atomic 包 里 的 类 基本 都 是 使 用 Unsafe 实 现 的 ， 让 我 们 一 起 看 
一 下 Unsafe 的 源码 ， 如 代码 清单 7-3 所 示 。 


代码 清单 7-3 Unsafe.java 





py 
* 如 果 当 前 数值 是 expected， 则 原子 的 将 Java 变 量 更 新 成 X 
* @return 如 果 更 新 成 功 则 返回 true 
二 1 

















public final native boolean compareAndSwapObject(0Object 0， 
long offset, 
Object expected, 
Object x); 
public final native boolean compareAndSwapInt(Object o, long offset, 
int expected, 
int x); 
public final native boolean compareAndSwapLong(Object o, long offset, 
long expected, 
long x); 


[ee | 


通过 代码 ， 我 们 发 现 Unsafe 只 提供 了 3 种 CAS 方 法 : 
compareAndSwapObject、compare-AndSwapInt 和 
compareAndSwapLong， 再 看 AtomicBoolean 源 码 ， 发 现 它 是 先 把 Boolean 
转换 成 整 型 ， 再 使 用 compareAndSwapInt 进 行 CAS， 所 以 原子 更 新 char、 
float 和 double 变 量 也 可 以 用 类 似 的 思路 来 实现 。 


7.2 原子 更 新 数组 


通过 原子 的 方式 更 新 数组 里 的 人 条 个 元 素 ，Atomic 包 提供 了 以 下 4 个 


类 。 
:AtomicIntegetArtay: 原子 更 新 整 型 数组 里 的 元 素 。 
" AtomicLongArray: 原子 更 新 长 整 型 数组 里 的 元 素 。 
. AtomicReferenceAttay: 原子 更 新 引用 类 型 数组 里 的 元 素 。 


* AtomicIntegetAttay 类 主要 是 提供 原子 的 方式 更 新 数组 里 的 整 型 ， 
其 常用 方法 如 下 。 
.intaddAndGet (inti，intdelta) : 以 原子 方式 将 输入 值 与 数组 


中 索引 i 的 元 素 相 加 。 


* boolean compareAndSet (inti，int expect，int update) : 如 果 当 


前 值 等 于 预期 值 ， 则 以 原子 方式 将 数组 位 置 i 的 元 素 设置 成 update 值 。 


以 上 几 个 类 提供 的 方法 几乎 一 样 ， 所 以 本 节 仅 以 AtomicIntegerArray 
为 例 进行 讲解 ，AtomicIntegerArray 的 使 用 实例 代码 如 代码 清单 7-4 所 


四 \。 


代码 清单 7-4 AtomicIntegerArrayTest.java 


和 


public class AtomicIntegerArrayTest { 
static int[] value = new int[] { 1, 2 }; 
static AtomicIntegerArray al = new AtomicIntegerArray(value); 
public static void main(String[] args) { 
ai.getAndSset(0, 3); 
System,.out.printin(ai.get(0)); 
System,out.printJln(value[0])， 





以 下 是 输出 的 结 





CD 








需要 注意 的 是 ， 数 组 value 通 过 构造 方法 传递 进去 ， 然 后 
AtomicIntegerArray 会 将 当前 数组 复制 一 份 ， 所 以 当 AtomicIntegerArray 
对 内 部 的 数组 元 素 进 行 修改 时 ， 不 会 影响 传 入 的 数组 。 








7.3 ”原子 更 新 引用 类 型 


原子 更 新 基本 类 型 的 AtomicInteger， 只 能 更 新 一 个 变量 ， 如 果 要 原 
子 更 新 多 个 变量 ， 就 需要 使 用 这 个 原子 更 新 引用 类 型 提供 的 类 。Atomic 
包 提 供 了 以 下 3 个 类 。 





AtomicReference: 原子 更 新 引用 类 型 。 
* AtomicReferenceFieldUpdater: 原子 更 新 引用 类 型 里 的 字段 。 


. AtomicMatkableRefetrence: 原子 更 新 带 有 标记 位 的 引用 类 型 。 可 
以 原子 更 新 一 个 布尔 类 型 的 标记 位 和 引用 类 型 。 构 造 方法 是 


AtomicMarkableReference (V initial]Ref，boolean initialMark) 。 


以 上 几 个 类 提供 的 方法 几乎 一 样 ， 所 以 本 节 仪 以 AtomicReference 为 
例 进 行 讲解 ，AtomicReference 的 使 用 示例 代码 如 代码 清单 7-5 所 示 。 


代码 清单 7-5 AtomicReferenceTest.java 





public class AtomicReferenceTest { 
public static AtomicReference<user> atomicUserRef = new 
AtomicReference<user>(); 

public static void main(String[] args) { 
User user = new User("conan", 15); 
atomicUserRef .set(user); 
User updateUser = new User("Shinichi", 17); 
atomicUserRef.compareAndSet(user, updateUser); 
System,out.printJln(atomicUserRef .get().getName()); 
System.out.printin(atomicUserRef .get().geto0Old()); 


static class User { 
private String name; 


private int old; 

public User(String name, int old) { 
this.name = name; 
this.old = old; 


public String getName() { 
return name; 


} 

public int getold() { 
return old; 

} 





代码 中 首先 构建 一 个 user 对 象 ， 然 后 把 user 对 象 设置 进 
AtomicReferenc 中 ， 最 后 调用 compareAndSet 方 法 进行 原子 更 新 操作 ， 实 
现 原理 同 AtomicInteger 里 的 compareAndSet 方 法 。 代 码 执行 后 输出 结果 
Wl hs 





Shinichi 
17 





7.4 原子 更 新 字段 类 


如 采 需 原子 地 更 新 茶 个 类 里 的 茶 个 字段 时 ， 束 需要 使 用 原子 更 新 字 
段 类 ，Atomic 包 提供 了 以 下 3 个 类 进行 原子 字段 更 新 。 





* AtomicIntegerFieldUpdater: 原子 更 新 整 型 的 字段 的 更 新 器 。 
* AtomicLongFieldUpdater: 原子 更 新 长 整 型 字段 的 更 新 器 。 


* AtomicStampedReference: 原子 更 新 带 有 版 本 号 的 引用 类 型 。 该 类 
将 整数 值 与 引用 关联 起 来 ， 可 用 于 原子 的 更 新 数据 和 数据 的 版 本 号 ， 可 
以 解决 使 用 CAS 进 行 原子 更 新 时 可 能 出 现 的 ABA 问 题 。 





要 想 原子 地 更 新 字段 类 需要 两 步 。 第 一 步 ， 因 为 原子 更 新 字段 类 都 
是 抽象 类 ， 每 次 使 用 的 时 候 必 须 使 用 静态 方法 newUpdater() 创 建 一 个 更 
新 器 ， 并 且 需 要 设置 想 要 更 新 的 类 和 属性 。 第 二 步 ， 更 新 类 的 字段 ( 属 
性 ) 必须 使 用 public volatile 修 饰 符 。 





以 上 3 个 类 提供 的 方法 几乎 一 样 ， 所 以 本 他 仅 以 
AstomicIntegerFieldUpdater 为 例 进行 讲解 ，AstomicIntegerFieldUpdater 的 
示例 代码 如 代码 清单 7-6 所 示 。 


代码 清单 7-6 AtomicIntegerFieldUpdaterTest.java 





public class AtomicIntegerFieldUpdaterTest { 

// 创建 原子 更 新 器 ， 并 设置 需要 更 新 的 对 象 类 和 对 象 的 属性 
private static AtomicIintegerFieldUpdater<User> a = AtomicIintegerFieldUpdater 
newUpdater(User.class, "old"); 
public static void main(String[] args) { 

// 设置 柯南 的 年 龄 是 10 岁 

User conan = new User("conan", 10); 

// 柯南 长 了 一 岁 ， 但 是 仍然 会 输出 旧 的 年 龄 

System.out.printin(a.getAndIncrement(conan)); 

// 输出 柯南 现在 的 年 龄 

System.out.printin(a.get(conan)); 




























































































} 


public static class User { 

private String name; 

public volatile int old; 

public User(String name, int old) { 
this.name = name; 
this.old = old; 

} 

public String getName() { 
return name; 


} 

public int getold() { 
return old; 

} 





代码 执行 后 输出 如 下 。 





10 
11 





7.5 ”本 章 小 结 


本 章 介 绍 了 JDK 中 并 发 包 里 的 13 个 原子 操作 类 以 及 原子 操作 类 的 实 
现 原理 ， 读 者 需要 画 秋 这些 类 和 使 用 场景 ， 在 适当 的 场合 下 使 用 它 。 


第 8 章 Java 中 的 并 发 工具 类 


在 JDK 的 并 发 包 里 提供 了 几 个 非常 有 用 的 并 发 工具 类 。 
CountDownLatch、CyclicBarrier 和 Semaphore 工 具 类 提供 了 一 种 并 发 流程 
控制 的 手段 ，Exchanger 工 具 类 则 提供 了 在 线程 间 交 换 数 据 的 一 种 手 
段 。 本 章 会 配合 一 些 应 用 场景 来 介绍 如 何 使 用 这 些 工具 类 ，。 





8.1 等 待 多 线程 完成 的 CountDownLatch 


CountDownLatch 人 允许 一 个 或 多 个 线程 等 竺 其 他 线程 完成 操作 。 


假如 有 这 样 一 个 需求 : 我 们 需要 解析 一 个 Excel 里 多 个 sheet 的 数 
据 ， 此 时 可 以 考虑 使 用 多 线程 ， 每 个 线程 解析 一 个 sheet 里 的 数据 ， 等 到 
所 有 的 sheet 都 解析 完 之 后 ， 程 序 需 要 提示 解析 完成 。 在 这 个 需求 中 ， 要 
实现 主线 程 等 待 所 有 线程 完成 sheet 的 解析 操作 ， 最 简单 的 做 法 是 使 用 
join0 方 法 ， 如 代码 清单 8-1 所 示 。 








代码 清单 8-1 JoinCountDownLatchTest.java 





public class JoinCountDownLatchTest { 
public static void main(String[] args) throws InterruptedException { 
Thread parser1 = new Thread(new Runnable() { 
@Override 
public void run() { 
} 


}); 
Thread parser2 = new Thread(new Runnable() { 
@Override 
public void run() { 
System,.out.println("parser2 finish"); 


parser1.start(); 
parser2.start(); 
parser1.join(); 
parser2.join(); 
System.out.printin("all parser finish"),; 





join 用 于 让 当前 执行 线程 等 竺 join 线程 执行 结束 。 其 实现 原理 是 不 俘 
检查 join 线程 是 人 否 存活 ， 如 采 join 线 程 存活 则 让 当前 线程 永远 等 待 。 其 


中 ，wait (0) 表示 永远 等 待 下去， 代码 片段 如 下 。 





while (isAlive()) { 
wait(0); 





直到 join 线程 中 止 后 ， 线 程 的 this.notifyAl10 方 法 会 被 调用 ， 调 用 
notifyAl10 方 法 是 在 JVM 里 实现 的 ， 所 以 在 JDK 里 看 不 到 ， 大 家 可 以 碍 看 
JVM 源 人 码 。 


在 JDK 1.5 之 后 的 并 发 包 中 提供 的 CountDownLatch 也 可 以 实现 join 的 
功能 ， 并 且 比 join 的 功能 更 多 ， 如 代码 清单 8-2 所 示 。 


代码 清单 8-2 CountDownLatchTest.java 





public class CountDownLatchTest { 
staticCountDownLatch c = new CountDownLatch(2); 
public static void main(String[] args) throws InterruptedException { 
new Thread(new Runnable() { 
@Override 
public void run() { 
System,.out.println(1); 
c.countDown(); 
System,.out.println(2); 
c.countDown(); 


+ 
}).start(); 


c.await(); 
System,.out.println("3"); 


} 





CountDownLatch 的 构造 函数 接收 一 个 int 类 型 的 参数 作为 计数 器 ， 
如 果 你 想 等 待 N 个 点 完成 ， 这 里 就 传 入 N。 





当 我 们 调用 CountDownLatch 的 countDown 方 法 时 ，N 就 会 减 1， 
CountDownLatch 的 await 方 法 会 阻塞 当前 线程 ， 直 到 N 变 成 零 。 由 于 
countDown 方 法 可 以 用 在 任何 地 方 ， 所 以 这 里 说 的 N 个 点 ， 可 以 是 N 个 线 
程 ， 也 可 以 是 1 个 线程 里 的 N 个 执行 步骤 。 用 在 多 个 线程 时 ， 只 需要 把 
这 个 CountDownLatch 的 引用 传递 到 线程 里 即 可 。 





如 果 有 茶 个 解析 sheet 的 线程 处 理 得 比较 慢 ， 我 们 不 可 能 让 主线 程 一 
直 等 待 ， 所 以 可 以 使 用 另外 一 个 带 指 定时 间 的 await 方 法 
time，TimeUnit unit) ， 这 个 方法 等 等 特定 时 间 后 ， 束 会 不 再 阻 窄 当 前 
线程 。join 也 有 类 似 的 方法 。 





await (long 


人 注意 ”计数 器 必须 大 于 等 于 0， 只 是 等 于 0 时 候 ， 计 数 器 就 是 
零 ， 调 用 await 方 法 时 不 会 阻塞 当前 线程 。CouhntDownLatch 不 可 能 重新 初 
始 化 或 者 修改 CountDownLatch 对 象 的 内 部 计数 器 的 值 。 一 个 线程 调用 


countDown 方 法 happen-befote， 另 外 一 个 线程 调用 await 方 法 。 


8.2 ”同步 屏障 CyclicBarrier 


CyclicBarrier 的 字面 意思 是 可 循环 使 用 (Cydlic〉 的 屏障 
(Barrier) 。 它 要 做 的 事情 是 ， 让 一 组 线程 到 达 一 个 屏障 《也 可 以 叫 同 
步 点 ) 时 被 阻塞 ， 直 到 最 后 一 个 线程 到 达 屏 障 时 ， 屏 障 才 会 开门 ， 所 有 
被 屏障 拦截 的 线程 才 会 继续 运行 。 


8.2.1 CydlicBarrier 人 简介 


CyclicBarrier 默 认 的 构造 方法 是 CyclicBarrier (int parties) ， 其 参数 
表示 屏障 拦截 的 线程 数量 ， 每 个 线程 调用 await 方 法 告诉 CyclicBarrier 我 
已 经 到 达 了 屏障 ， 然 后 当前 线程 被 阻 罕 。 示 例 代 人 码 如 代码 清单 8-3 所 


A 


代码 清单 8-3 CydlicBarrierTest.java 





public class CyclicBarrierTest { 
staticCyclicBarrier c = new CyclicBarrier(2); 
public static void main(String[] args) { 
new Thread(new Runnable() { 
@Override 
public void run() { 
try { 
c.await( ); 
} catch (Exception e) { 


System,out.printJln(1)， 


} 
}).start(); 


try { 
c.await( ); 
} catch (Exception e) { 
System.out.printlin(2); 
} 
} 





因为 主线 程 和 子 线程 的 调度 是 由 CPU 决定 的 ， 两 个 线程 都 有 可 能 
执行 ， 所 以 会 产生 两 种 输出 ， 第 一 种 可 能 输出 如 下 。 





HA 





第 二 种 可 能 输出 如 下 。 





Dh 





如 果 把 new CydlicBarrier(2) 修 改 成 new CyclicBarrier(3)， 则 主线 程 和 
子 线程 会 永远 等 待 ， 因 为 没有 第 三 个 线程 执行 await 方 法 ， 即 没有 第 三 个 


线程 到 达 屏 障 ， 所 以 之 前 到 达 屏 障 的 两 个 线程 都 不 会 继续 执行 。 


CyclicBarrier 还 提供 一 个 更 高 级 的 构造 函数 CyclicBarrier (int 
parties，Runnable barrier-Action) ， 用 于 在 线程 到 达 屏 障 时 ， 优 先 执行 
barrierAction， 方 便 处 理 更 复杂 的 业务 场景 ， 如 代码 清单 8-4 所 示 。 


代码 清单 8-4 CyclicBarrierTest2.java 





import java.util.concurrent.CyclicBarrier,; 
public class CyclicBarrierTest2 区 
static CyclicBarrier c = new CyclicBarrier(2, new A()); 
public static void main(String[] args) { 
new Thread(new Runnable() { 
Q@Override 
public void run() { 
try { 
c.await(); 
} catch (Exception e) { 


System.out.printlin(1); 


} 
}).start(); 
try { 
c.await(); 
} catch (Exception e) { 


System.out.printin(2); 


static class A implements Runnable { 
Q@Override 
public void run() { 
System,.out.println(3); 
} 








因为 CyclicBarrier 设 置 了 拦截 线程 的 数量 是 2， 所 以 必须 等 代码 中 的 
第 一 个 线程 和 线程 A 都 执行 完 之 后 ， 才 会 继续 执行 主线 程 ， 然 后 输出 
2， 所 以 代码 执行 后 的 输出 如 下 。 


DOPO 


8.2.2 ”CydlicBarrier 的 应 用 场景 








CyclicBarrier 可 以 用 于 多 线程 计算 数据 ， 最 后 合并 计算 结果 的 场 
景 。 例 如 ， 用 一 个 Excel 保 存 了 用 户 所 有 银行 流水 ， 每 个 Sheet 保 存 一 个 
账户 近 一 年 的 每 笔 银行 流水 ， 现 在 需要 统计 用 户 的 日 均 银 行 流水 ， 先 用 
多 线程 处 理 每 个 sheet 里 的 银行 流水 ， 都 执行 完 之 后 ， 得 到 每 个 sheet 的 日 
均 银 行 流水 ， 最 后 ， 再 用 barrierAction 用 这 些 线程 的 计算 结果 ， 计 算出 
整个 Excel 的 日 均 银 行 流水 ， 如 代码 清单 8-5 所 示 。 


代码 清单 8-5 BankWaterService.java 





import java.util.Map.Entry; 

import java.util.concurrent.BrokenBarrierException; 
import java.util.concurrent.ConcurrentHashMap; 
import java.util.concurrent.CyclicBarrier; 

import java.util.concurrent.Executor; 

import java.util.concurrent.Executors; 


* 银行 流水 处 理 服 务 类 





* @authorftf 
* 


*/ 
publicclass BankWaterService implements Runnable { 
yA 























* 创建 4 个 屏障 ， 处 理 完 之 后 执行 当前 类 的 run 方 法 
*/ 


private CyclicBarrier c = new CyclicBarrier(4, this); 
/** 




















* 假设 只 有 4 个 sheet， 所 以 只 启动 4 个 线程 

*/ 

private Executor executor = Executors.newFixedThreadPool1(4); 
/A** 

* 保存 每 个 sheet 计 算出 的 银 流 结果 

WA 








private ConcurrentHashMap<String, Integer>sheetBankwWaterCount = new 
ConcurrentHashMap<String, Integer>(); 
privatevoid count() { 
for (inti = 0; i< 4; i++) { 
executor .execute(new Runnable() { 


@Override 
publicvoid run() { 
// 计算 当前 sheet 的 银 流 数据 ， 计 算 代码 省 略 
sheetBankwaterCount 
.put(Thread.currentThread().getName(), 1); 
// 银 流 计算 完成 ， 插 入 一 个 屏障 
try { 



































c.await(); 
} catch (InterruptedException | 
BrokenBarrierException e) { 
e.printStackTrace( ); 


}); 
} 


@Override 
publicvoid run() { 
intresult = 0; 
// 汇总 每 个 sheet 计 算出 的 结果 
for (Entry<String, Integer>sheet : SheetBankwaterCount .entrySet()) 1 
result += sheet.getValue(); 








} 

// 将 结果 输出 
sheetBankwaterCount.put("result", result); 
System,out.printJln(result ) ， 


publicstaticvoid main(String[] args) { 
BankwaterService bankWaterCount = new BankwaterService(); 
bankwaterCount .count () ， 





使 用 线程 池 创 建 4 个 线程 ， 分 别 计算 每 个 sheet 里 的 数据 ， 每 个 sheet 
计算 结果 是 1， 再 由 BankWaterService 线 程 汇总 4 个 sheet 计 算出 的 结果 ， 
输出 结果 如 下 。 








8.2.3 ”CyclicBarrier 和 CountDownLatch 的 区 别 


CountDownLatch 的 计数 占 只 能 使 用 一 次 ， 而 CyclicBarrier 的 计数 器 
可 以 使 用 reset(0) 方 法 重 置 。 所 以 CyclicBarrier 能 处 理 更 为 复杂 的 业务 场 
景 。 例 如 ， 如 果 计 算 发 生 错 误 ， 可 以 重 置 计 数 器 ， 并 让 线程 重新 执行 一 


次 。 


CyclicBarrier 还 提供 其 他 有 用 的 方法 ， 比 如 getNumberWaiting 方 法 可 
以 获得 Cyclic-Barrier 阻 塞 的 线程 数量 。isBroken() 方 法 用 来 了 解 阻塞 的 线 
时 是 否 被 中 断 。 代 码 清单 8-5 执 行 完 之 后 会 返回 true， 其 中 isBroken 的 使 
用 代码 如 代码 清单 8-6 所 示 。 


代码 清单 8-6 ”CyclicBarrierTest3.java 





importjava.util.concurrent.BrokenBarrierException,; 
importjava.util.concurrent.CyclicBarrier,; 
public class CyclicBarrierTest3 { 
staticCyclicBarrier c = new CyclicBarrier(2); 
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException { 
Thread thread = new Thread(new Runnable() { 


@Override 
public void run() { 
try { 
c.await( ); 


} catch (Exception e) { 


} 


}); 
thread. start(); 
thread.interrupt(); 
try { 
c.await( ); 

} catch (Exception e) { 
System,.out.println(c.isBroken()); 


输出 如 下 所 示 。 


true 


8.3 控制 并 发 线程 数 的 Semaphore 








Semaphore 〈 信 和 号 量 ) 是 用 来 控制 同时 访问 特定 资源 的 线程 数量 ， 
它 通 过 协调 各 个 线程 ， 以 保证 合理 的 使 用 公共 资源 。 


多 年 以 来 ， 我 都 党 得 从 字面 上 很 难 理解 Samaphore 所 表达 的 合 义 ， 

只 能 把 它 比 作 是 控制 流量 的 红绿灯 。 比 如 xx 马路 要 限制 流量 ， 只 人 允许 同 
时 有 一 百 辆 车 在 这 条 路 上 行使 ， 其 他 的 都 必须 在 路 口 等 待 ， 所 以 前 一 百 
辆 车 会 看 到 绿灯 ， 可 以 开 进 这 条 马路 ， 后 面 的 车 会 看 到 红 灯 ， 不 能 驶 入 
xx 马 路 ， 但 是 如 朵 前 一 百 辆 中 有 5 辆 车 已 经 离开 了 xx 马 路 ， 那 么 后 面 就 
允许 有 5 辆 车 驶 入 马路 ， 这 个 例子 里 说 的 车 束 是 线程 ， 驶 入 马路 就 表示 
线程 在 执行 ， 离 开 蕊 路 就 表示 线程 执行 完成 ， 看 见 红 娄 就 表示 线程 被 阻 
答 ， 不 能 执行 。 





1. 应 用 场景 


Semaphore 可 以 用 于 做 流量 控制 ， 特 别 是 公用 资源 有 限 的 应 用 场 
景 ， 比 如 数据 库 连 接 。 假 如 有 一 个 需求 ， 要 读 取 几 万 个 文件 的 数据 ， 因 
为 都 是 IO 密集 型 任务 ， 我 们 可 以 局 动 几 十 个 线程 并 发 地 读 取 ， 但 是 如 宁 
读 到 内 存 后 ， 还 需要 存储 到 数据 库 中 ， 而 数据 库 的 连接 数 只 有 10 个 ， 这 
时 我 们 必须 控制 只 有 10 个 线程 同时 获取 数据 库 连 接 保存 数据 ， 人 否则 会 报 
普 无 法 获取 数据 库 连 接 。 这 个 时 候 ， 束 可 以 使 用 Semaphore 来 做 流量 控 


制 ， 如 代码 清单 8-7 所 示 。 


代码 清单 8-7 SemaphoreTest.java 





public class SemaphoreTest { 
private static final int THREAD_ COUNT = 30; 
private static ExecutorServicethreadPool = Executors 
.NewFixedThreadPool(THREAD_ COUNT); 
private static Semaphore s = new Semaphore(10); 
public static void main(String[] args) { 
for (inti = 0; i< THREAD_ COUNT; i++) { 
threadPool.execute(new Runnable() { 
@Override 
public void run() { 
try { 
s.acquire(); 
System.out.printilin("save data"); 
s.release(); 
} catch (InterruptedException e) { 


} 
}); 


} 
threadPool. shutdown( ); 


} 





在 代码 中 ， 虽 然 有 30 个 线程 在 执行 ， 但 是 只 允许 10 个 并 发 执行 。 
Semaphore 的 构造 方法 Semaphore (int permits) 接受 一 个 整 型 的 数字 ， 
表示 可 用 的 许可 证 数量 。Semaphore (10) 表示 人 允许 10 个 线程 获取 许可 
证 ， 也 就 是 最 大 并 发 数 是 10。Semaphore 的 用 法 也 很 简单 ， 首 先 线程 使 
用 Semaphore 的 acquire() 方 法 获取 一 个 许可 证 ， 使 用 完 之 后 调用 release() 
方法 归还 许可 证 。 还 可 以 用 tryAcquire() 方 法 尝试 获取 许可 证 。 


2. 其 他 方法 


Semaphore 还 提供 一 些 其 他 方法 ， 具 体 如 下 。 


.intavailablePetrmits0: 返回 此 信号 量 中 当前 可 用 的 许可 证 数 。 
` intgetQueueLength0: 返回 正在 等 待 获取 许可 证 的 线程 数 。 
:booleanhasQueuedThreads0: 是 否 有 线程 正在 等 待 获 取 许 可 证 。 


. void reducePermits (int teduction) : 减少 reduction 个 许可 证 ， 是 个 


protected 方 法 。 


:Collection getQueuedThreads0: 返回 所 有 等 待 获取 许可 证 的 线程 集 


合 ， 是 个 pfotected 方 法 。 


8.4 ”线程 间 交 换 数据 的 Exchanger 


Exchanger〈 交 换 者 ) 是 一 个 用 于 线程 间 协 作 的 工具 类 。Exchanger 
用 于 进行 线程 间 的 数据 交换 。 饭 提供 一 个 同步 点 ， 在 这 个 同步 点 ， 两 个 
线程 可 以 交换 彼此 的 数据 。 这 两 个 线程 通过 exchange 方 法 交换 数据 ， 如 
果 第 一 个 线程 完 执 行 exchange() 方 法 ， 它 会 一 直 等 待 第 二 个 线程 也 执行 
exchange 方 法 ， 当 两 个 线程 都 到 达 同 步 点 时 ， 这 两 个 线程 束 可 以 交换 数 
据 ， 将 本 线程 生产 出 来 的 数据 传递 给 对 方 。 





下 面 来 看 一 下 Exchanger 的 应 用 场景 。 


Exchanger 可 以 用 于 遗传 算法 ， 遗 传 算法 里 需要 选 出 两 个 人 作为 交 
配对 象 ， 这 时 候 会 交换 两 人 的 数据 ， 并 使 用 交叉 规则 得 出 2 个 交配 结 
果 。Exchanger 也 可 以 用 于 校对 工作 ， 比 如 我 们 需要 将 纸 制 银行 流水 通 
过 人 工 的 方式 录入 成 电子 银行 流水 ， 为 了 避免 错误 ， 采 用 AB 闵 两 人 进 
行 录入 ， 录 入 到 Excel 之 后 ， 系 统 需 要 加 载 这 两 个 Excel， 并 对 两 个 Excel 
数据 进行 校对 ， 看 看 是 人 否 录 入 一 致 ， 代 码 如 代码 清单 8-8 所 示 。 





代码 清单 8-8 ExchangerTest.java 





public class ExchangerTest { 
private static final Exchanger<String>exgr = new Exchanger<String>(); 
private static ExecutorServicethreadPool = Executors.newFixedThreadPoo1(2); 
public static void main(String[] args) { 
threadPool.execute(new Runnable() { 

@Override 
public void run() { 


try { 





String A = "银行 流水 A" ; // A 录入 银行 流水 数据 
exgr .exchange(A); 
} catch (InterruptedException e) { 
} 
} 


了 
threadPool.execute(new Runnable() { 
@Override 
public void run() { 
try { 





String B =“" 银 行 流水 B"，; // B 录 入 银行 流水 数据 
String A = exgr.exchange("B"); 
System.out.println("A 和 B 数 据 是 否 一 致 :" + A.equals(B) + "，A 录 入 的 是 : " 
+ AT+ "， B 录 入 是 : 0 十 B); 
} catch (InterruptedException e) { 
= 





} 
}); 
threadPool. shutdown( ); 
} 
} 





如 果 两 个 线程 有 一 个 没有 执行 exchange() 方 法 ， 则 会 一 直 等 待 ， 如 
果 担 心 有 特 殊 情 况 发 生 ， 避 人 免 一 直 等 待 ， 可 以 使 用 exchange (VX， 


longtimeout，TimeUnit unit) 设置 最 大 等 待 时 长 。 





8.5 ”本 章 小 结 


本 章 配 合 一 些 应 用 场景 介绍 JDK 中 提供 的 几 个 并 发 工具 类 ， 大 家 记 
住 这 个 工具 类 的 用 途 ， 一 旦 有 对 应 的 业务 场景 ， 不 妨 试 试 这 些 工 具 类 。 





第 9 章 ”Java 中 的 线程 池 


Java 中 的 线程 池 是 运用 场景 最 多 的 并 友 框 染 ， 几 乎 所 有 需要 异步 或 
并 发 执行 任务 的 程序 都 可 以 使 用 线程 池 。 在 开发 过 程 中 ,合理 地 使 用 线 
程 池 能 够 带 来 3 个 好 处 。 


第 一 :降低 资源 消耗 。 通 过 重复 利用 已 创建 的 线程 降低 线程 创建 
和 销毁 造成 的 消耗 。 


第 二 : 提高 啊 应 速度 。 当 任务 到 达 时 ， 任 务 可 以 不 需要 等 到 线程 
创建 就 能 立即 执行 。 


第 三 ;提高 线程 的 可 管理 性 。 线 程 是 稀缺 资源 ， 如 果 无 限制 地 创 
建 ， 不 仅 会 消耗 系统 资源 ， 还 会 降低 系统 的 稳定 性 ， 使 用 线程 池 可 以 进 
行 统一 分 配 、 调 优 和 监控 。 但 是 ， 要 做 到 合理 利用 线程 地， 必须 对 其 实 
现 原理 了 如 指 掌 。 


9.1 线程 池 的 实现 原理 


当 向 线程 池 提交 一 个 任务 之 后 ， 线 程 池 是 如 何 处 理 这 个 任务 的 呢 ? 
本 节 来 看 一 下 线程 池 的 主要 人 处理 流程 ， 处 理 流程 图 如 图 9-1 所 示 。 


从 图 中 可 以 看 出 ， 当 提交 一 个 新 任务 到 线程 池 时 ， 线 程 池 的 处 理 流 
程 如 下 。 


1) 线程 池 判 断 核心 线程 池 里 的 线程 是 否 都 在 执行 任务 。 如 果 不 
是 ， 则 创建 一 个 新 的 工作 线程 来 执行 任务 。 如 果 核 心 线 程 池 里 的 线程 都 
在 执行 任务 ， 则 进入 下 个 流程 。 


2) 线程 池 判 断 工 作 队 列 是 否 已 经 满 。 如 果 工 作 队 列 没 有 满 ， 则 将 
新 提交 的 任务 存储 在 这 个 工作 队列 里 。 如 有 果 工 作 队 列 满 了 ， 则 进入 下 个 


流程 。 


3) 线程 池 判 断 线 程 池 的 线程 是 否 都 处 于 工作 状态 。 如 果 没 有 ， 则 
创建 一 个 新 的 工作 线程 来 执行 任务 。 如 果 已 经 满 了 ， 则 交 给 饱和 策略 来 
处 理 这 个 任务 。 





ThreadPoolExecutor 执 行 execute() 方 法 的 示意 图 ， 如 图 9-2 所 示 。 





图 9-1 线程 池 的 主要 处 理 流程 
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图 9-2 ”ThreadPoolExecutot 执 行 示意 图 


ThreadPoolExecutor 执 行 execute 方 法 分 下 面 4 种 情况 


1) 如 果 当 前 运行 的 线程 少 于 corePoolSize， 则 创建 新 线程 来 执行 任 
务 〈 注 意 ， 执 行 这 一 步骤 需要 获取 全 局 锁 ) 。 





2) 如 果 运 行 的 线程 等 于 或 多 于 corePoolSize， 则 将 任务 加 入 
BlockingQueue。 


3) 如 果 无 法 将 任务 加 入 BlockingQueue〈 队 列 已 满 ) ， 则 创建 新 的 
线程 来 处 理 任务 〈 注 意 ， 执 行 这 一 步骤 需要 获取 全 局 锁 ) 。 


4) 如 果 创 建新 线程 将 使 当前 运行 的 线程 超出 maximumPoolSize， 任 
务 将 被 拒绝 ， 并 调用 RejectedExecutionHandler.rejectedExecution() 方 法 。 


ThreadPoolExecutor 采 取 上 述 步 骤 的 总 体 设计 思路 ， 是 为 了 在 执行 
execute() 方 法 时 ， 尽 可 能 地 避免 获取 全 局 锁 〈 那 将 会 是 一 个 严重 的 可 伸 
缩 瓶颈 ) 。 在 ThreadPoolExecutor 完 成 预 热 之 后 〈 当 前 运行 的 线程 数 大 
于 等 于 corePoolSize) ， 几 乎 所 有 的 execute() 方 法 调用 都 是 执行 步骤 2， 
而 步骤 2 不 需要 获取 全 局 锁 。 





源码 分 析 : 上 面 的 流程 分 析 让 我 们 很 直观 地 了 解 了 线程 池 的 工作 
原理 ， 让 我 们 再 通过 源 代 码 来 看 看 是 如 何 实现 的 ， 线 程 池 执行 任务 的 方 
法 如 下 。 





public void execute(Runnable command ) { 

If (command == null) 

throw new NullPointerException(); 

// 如 果 线 程 数 小 于 基本 线程 数 ， 则 创建 线程 并 执行 当前 任务 
if (poolSize >= corePoolSize || !addIfUnderCorePoolSize(command)) { 
// 如 线程 数 大 于 等 于 基本 线程 数 或 线程 创建 失败 ， 则 将 当前 任务 放 到 工作 队列 中 。 
if (runState == RUNNING && workQueue.offer(command)) { 

If (runState != RUNNING || poolSize == 0) 

ensureQueuedTaskHandled(command); 















































} 

// 如 果 线 程 池 不 处 于 运行 中 或 任务 无 法 放 入 队列 ， 并 且 当 前 线程 数量 小 于 最 大 允许 的 线程 数量 ， 
// 则 创建 一 个 线程 执行 任务 。 

else if (!addIifUnderMaximumPoolSize(command)) 

// 抛 出 RejectedExecutionException 异 常 

reject(command); // is shutdown or Saturated 


} 


二 一 

















工作 线程 : 线程 池 创 建 线程 时 ， 会 将 线程 封装 成 工作 线程 
Worker，Worker 在 执行 完 任务 后 ， 还 会 循环 获取 工作 队列 里 的 任务 来 执 
行 。 我 们 可 以 从 Worker 类 的 run0 方 法 里 看 到 这 点 。 





public void run() { 
try { 
Runnable task = firstTask; 
firstTask = null; 
while (task != null || (task = getTask()) != null) { 
runTask(task); 
task = null; 


} 
} finally { 
workerDone(this ) ， 
} 


} 





ThreadPoolExecutor 中 线程 执行 任务 的 示意 图 如 图 9-3 所 示 。 


BlockingQueue<Runnable> 







图 9-3 ”ThteadPoolExecutot 执 行 任务 示意 图 
线程 池 中 的 线程 执行 任务 分 两 种 情况 ， 如 下 。 


1) 在 execute0) 方 法 中 创建 一 个 线程 时 ， 会 让 这 个 线程 执行 当前 任 


2) 这 个 线程 执行 完 上 图 中 1 的 任务 后 ， 会 反复 从 BlockingQueue 获 
取 任 务 来 执行 。 


9.2 ”线程 池 的 使 用 


9.2.1 ”线程 池 的 创建 


我 们 可 以 通过 ThreadPoolExecutor 来 创建 一 个 线程 池 。 





new ThreadPoolExecutor(corePoolSize, maximumPoolSize, keepAliveTime, 
milliseconds,runnableTaskQueue, handler); 





创建 一 个 线程 池 时 需要 输入 几 个 参数 ， 如 下 。 


1) corePoolSize《〈 线 程 池 的 基本 大 小 ) : 当 提 交 一 个 任务 到 线程 池 
时 ， 线 程 池 会 创建 一 个 线程 来 执行 任务 ， 即 使 其 他 空闲 的 基本 线程 能 够 
执行 新 任务 也 会 创建 线程 ， 等 到 需要 执行 的 任务 数 大 于 线程 池 基 本 大 小 
时 就 不 再 创建 。 如 果 调 用 了 线程 池 的 prestartAllCoreThreads() 方 法 ， 线 程 
池 会 提前 创建 并 局 动 所 有 基本 线程 。 


2) runnableTaskQueue (任务 队列 ) : 用 于 保存 等 待 执行 的 任务 的 
阻塞 队列 。 可 以 选择 以 下 几 个 阻 赛 队列 。 


* AttayBlockinegeQueue: 是 一 个 基于 数组 结构 的 有 界 阻 塞 队 列 ， 此 队 


列 按 FIFO (先进 先 出 ) 原则 对 元 素 进行 排序 。 


LinkedBlockingQueue: 一 个 基于 链表 结构 的 阻塞 队列 ， 此 队列 按 


FIFO 排 序 元 素 ， 吞 吐 量 通 常 要 高 于 ArrayBlockineQueue。 静 态 工厂 方法 
Executors.newFixedThreadPool0 使 用 了 这 个 队列 。 


.SynchronousQueue: 一 个 不 存储 元 素 的 阻塞 队列 。 每 个 插入 操作 
必须 等 到 另 一 个 线程 调用 移 除 操作 ， 否 则 插入 操作 一 直 处 于 阻塞 状态 
吞吐 量 通常 要 高 于 Linked-BlockingQueue， 静 态 工厂 方法 
Executors.newCachedThreadPool 使 用 了 这 个 队列 。 


PriorityBlockingQueue: 一 个 具有 优先 级 的 无 限 阻塞 队列 。 


3) maximumPoolSize 线程 池 最 大 数量 ) : 线程 池 人 允许 创建 的 最 大 
线程 数 。 如 果 队 列 满 了 ， 并 且 已 创建 的 线程 数 小 于 最 大 线程 数 ， 则 线程 
凶 会 再 创建 新 的 线程 执行 任务 。 值 得 注意 的 是 ， 如 果 使 用 了 无 界 的 任务 
队列 这 个 参数 融 没 什么 效果 。 





4) ThreadFactory: 用 于 设置 创建 线程 的 工厂 ， 可 以 通过 线程 工厂 
给 每 个 创建 出 来 的 线程 设置 更 有 意义 的 名 字 。 使 用 开源 框架 guava 提 供 
的 ThreadFactoryBuilder 可 以 快速 给 线程 池 里 的 线程 设置 有 意义 的 名 字 ， 
代码 如 下 





new ThreadFactoryBuilder().setNameFormat("XX-task-%d").build(); 





5) RejectedExecutionHandler〈 饱 和 策略 ) : 当 队 列 和 线程 池 都 满 
了 ， 说 明 线 程 池 处 于 饱和 状态 ， 那 么 必须 采取 一 种 策略 处 理 提交 的 新 任 


务 。 这 个 策略 默认 情况 下 是 AbortPolicy， 表 示 无 法 处 理 新 任务 时 抛 出 异 
常 。 在 JDK 1.5 中 Java 线 程 池 框架 提供 了 以 下 4 种 策略 。 


* AbortPolicy: 直接 抛 出 异常 。 
. CallefRunsPolicy: 只 用 调用 者 所 在 线程 来 运行 任务 。 


. DiscatdOldestPolicy: 丢弃 队列 里 最 近 的 一 个 任务 ， 并 执行 当前 任 


务 


* DiscardPolicy: 不 处 理 ， 丢 弃 掉 。 


当然 ， 也 可 以 根据 应 用 场景 需要 来 实现 RejectedExecutionHandler 接 
口 目 定义 策略 。 如 记录 日 志 或 持久 化 存储 不 能 处 理 的 任务 。 


` keepAliveTime (线程 活动 保持 时 间 ) : 线程 池 的 工作 线程 空闲 
后 ， 保 持 存 活 的 时 间 。 所 以 ， 如 果 任 务 很 多 ， 并 且 每 个 任务 执行 的 时 间 
比较 短 ， 可 以 调 大 时 间 ， 提 高 线程 的 利用 率 。 


TimeUnit (线程 活动 保持 时 间 的 单位 ) : 可 选 的 单位 有 天 
(DAYS) 、 小 时 (HOURS) 、 分 钟 (MINUTES) 、 毫 秒 
(MILLISECONDS) 、 微 秒 (MICROSECONDS ， 千 分 之 一 毫秒 ) 和 纳 


秒 (NANOSECONDS， 千 分 之 一 微 秒 ) 。 


9.2.2” 回 线 程 池 提 区 任务 


可 以 使 用 两 个 方法 同 线程 池 提 交 任务 ， 分 别 为 execute() 和 submit() 方 


execute() 方 法 用 于 提交 不 需要 返回 值 的 任务 ， 所 以 无 法 判断 任务 是 
否 被 线程 池 执 行 成 功 。 通 过 以 下 代码 可 知 execute() 方 法 输入 的 任务 是 一 
个 Runnable 类 的 实例 。 





threadsPool.execute(new Runnable() { 
@Override 
public void run() 
// TODO Auto-generated method stub 
} 


}); 





en 回 值 的 任务 。 线 程 池 会 返回 一 个 future 
类 型 的 对 象 ， 这 个 future 对 象 可 以 判断 任务 是 否 执行 成 功 ， 并 且 可 
以 通过 future 的 get() 方 法 来 获取 返回 值 ，get() 方 法 会 阻塞 当前 线程 直到 任 

务 完成 ， 而 使 用 get (long timeout，TimeUnit unit) 方法 则 会 阻塞 当前 线 
程 一 段 时间 后 立即 返回 ， 这 时 候 有 可 能 任务 没有 执行 完 。 





Future<Object> future = executor.submit(harReturnValuetask); 
try { 
Object s = future.get(); 
} catch (InterruptedException e) { 
// 处 理 中 断 异常 
} catch (ExecutionException e) { 
/ 


/ 处 理 无 法 执行 任务 异常 
yi 
// 关闭 线程 池 

















} finall 


executor ,shutdown( ) ， 


9.2.3 ”关闭 线程 池 





可 以 通过 调用 线程 池 的 shutdown 或 shutdownNow 方 法 来 关闭 线程 
池 。 它 们 的 原理 是 过 历 线 程 池 中 的 工作 线程 ， 然 后 逐个 调用 线程 的 
interrupt 方 法 来 中 断 线 程 ， 所 以 无 法 啊 应 中 断 的 任务 可 能 永远 无 法 终 
止 。 但 是 它们 存在 一 定 的 区 别 ，shutdownNow 首 先 将 线程 池 的 状态 设置 
成 STOP， 然 后 尝试 停止 所 有 的 正在 执行 或 暂停 任务 的 线程 ， 并 返回 等 
待 执行 任务 的 列表 ， 而 shutdown 只 是 将 线程 池 的 状态 设置 成 
SHUTDOWN 状 态 ， 然 后 中 断 所 有 没有 正在 执行 任务 的 线程 。 




















只 要 调用 了 这 两 个 关闭 方法 中 的 任意 一 个 ，isShutdown 方 法 就 会 返 
回 tue。 当 所 有 的 任务 都 已 关闭 后 ， 才 表示 线程 池 关 闭 成 功 ， 这 时 调用 
isTerminaed 方 法 会 返回 true。 人 至 于 应 该 调用 哪 一 种 方法 来 关闭 线 程 池 ， 
应 该 由 提交 到 线程 池 的 任务 特性 决定 ， 通 第 调用 shutdown 方 法 来 关闭 线 
程 池 ， 如 采 任 务 不 一 定 要 执行 完 ， 则 可 以 调用 shutdownNow 方 法 。 








9.2.4 合理 地 配置 线程 池 


要 想 合理 地 配置 线程 池 ， 丈 必须 首先 分 析 任 务 特性 ， 可 以 从 以 下 几 
个 角度 来 分 析 。 


. 任务 的 性 质 : CPU 窗 集 型 任务 、IO 窗 集 型 任务 和 混合 型 任务 。 
` 任务 的 优先 级 : 高 、 中 和 低 。 

* 任务 的 执行 时 间 : 长 、 中 和 短 。 

任务 的 依赖 性 : 是 否 依赖 其 他 系统 资源 ， 如 数据 库 连接 。 


性 质 不 同 的 任务 可 以 用 不 同 规模 的 线程 池 分 开 处 理 。CPU 密 集 型 任 
务 应 配置 尽 可 能 小 的 线程 ， 如 配置 Neou +1 个 线程 的 线程 池 。 由 于 IO 密集 
型 任务 线程 并 不 是 一 直 在 执行 任务 ， 则 应 配置 尽 可 能 多 的 线程 ， 如 
2*Neou 。 混 合 型 的 任务 ， 如 果 可 以 拆 分 ， 将 其 拆 分 成 一 个 CPU 密集 型 任 
务 和 一 个 IO 密 集 型 任务 ， 只 要 这 两 个 任务 执行 的 时 间 相差 不 是 太 大 ， 那 
么 分 解 后 执行 的 吞吐 量 将 高 于 串 行 执行 的 吞吐 量 。 如 果 这 两 个 任务 执行 
时 间 相差 太 大 ， 则 没 必 要 进行 分 解 。 可 以 通过 
Runtime.getRuntime().availableProcessors() 方 法 获得 当前 设备 的 CPU 个 
数 。 

















优先 级 不 同 的 任务 可 以 使 用 优先 级 队列 PriorityBlockingQueue 来 处 
理 。 它 可 以 让 优先 级 高 的 任务 先 执行 。 


Oi 如 果 一 直 有 优先 级 高 的 任务 提交 到 队列 里 ， 那 么 优先 级 


低 的 任务 可 能 永远 不 能 执行 。 


执行 时 间 不 同 的 任务 可 以 交 给 不 同 规模 的 线程 池 来 处 理 ， 或 者 可 以 
使 用 优先 级 队列 ， 让 执行 时 间 短 的 任务 先 执 行 。 


依赖 数据 库 连接 池 的 任务 ， 因 为 线程 提交 SQL 后 需要 等 待 数据 库 返 
回 结果 ， 等 待 的 时 间 越 长 ， 则 CPU 空闲 时 间 就 越 长 ， 那 么 线程 数 应 该 设 
置 得 越 大 ， 这 样 才能 更 好 地 利用 CPU。 


建议 使 用 有 界 队 列 。 有 界 队列 能 增加 系统 的 稳定 性 和 预警 能 

可 以 根据 需要 设 大 一 点 儿 ， 比 如 几 千 。 有 一 次 ， 我 们 系统 里 后 合 任务 线 
程 池 的 队列 和 线程 池 全 满 了 ， 不 断 抛 出 抛弃 任务 的 寞 第， 通过 排 伍 太 现 
是 数据 库 出 现 了 问题 ， 导 致 执行 SQL 变 得 非常 缓慢 ， 因 为 后 台 任 务 线程 
池 里 的 任务 全 是 需要 回 数 据 库 查 询 和 插入 数据 的 ， 所 以 导致 线程 池 里 的 
工作 线程 全 部 阻 瞪 ,任务 积压 在 线程 池 里 。 如 末 当 时 我 们 设置 成 无 界 队 
列 ， 那 么 线程 池 的 队列 就 会 越 来 越 多 ， 有 可 能 会 撑 满 和 内存， 导致 整 个 系 
统 不 可 用 ， 而 不 只 是 后 台 任 务 出 现 问 题 。 当 然 ， 我 们 的 系统 所 有 的 任务 
古 用 单独 的 服务 怖 部 车 的 ， 我 们 使 用 不 同 规模 的 线程 池 完 成 不 同类 型 的 
任务 ， 但 是 出 现 这 样 问题 时 也 会 影响 到 其 他 任务 。 




















9.2.5 ”线程 池 的 监控 


如 果 在 系统 中 大 量 使 用 线程 池 ， 则 有 必要 对 线程 池 进 行 监控 ， 方 便 
在 出 现 问 题 时 ， 可 以 根据 线程 池 的 使 用 状况 快速 定位 问题 。 可 以 通过 线 
程 池 提供 的 参数 进行 监控 ， 在 监控 线程 池 的 时 候 可 以 使 用 以 下 属性 。 





* taskCount: 线程 池 需 要 执行 的 任务 数量 。 


completedTaskCount: 线程 池 在 运行 过 程 中 已 完成 的 任务 数量 ， 
小 于 或 等 于 taskCount。 


* largestPoolSize: 线程 池 里 曾经 创建 过 的 最 大 线程 数量 。 通 过 这 个 
数据 可 以 知道 线程 池 是 否 曾 经 满 过 。 如 该 数值 等 于 线程 池 的 最 大 大 小 ， 


则 表示 线程 池 曾 经 满 过 。 


.getPoolSize: 线程 池 的 线程 数量 。 如 果 线 程 池 不 销毁 的 话 ， 线 程 
池 里 的 线程 不 会 自动 销毁 ， 所 以 这 个 大 小 只 增 不 减 。 

.getActiveCount: 获取 活动 的 线程 数 。 

通过 扩展 线程 池 进 行 监控 。 可 以 通过 继承 线程 池 来 自 定 义 线 程 池 ， 
重 写 线程 池 的 beforeExecute、afterExecute 和 terminated 方 法 ， 也 可 以 在 任 
务 执 行 前 、 执 行 后 和 线程 池 关 闭 前 执行 一 些 代 码 来 进行 监控 。 例 如 ， 监 


控 任 务 的 平均 执行 时 间 、 最 大 执行 时 间 和 最 小 执行 时 间 等 。 这 几 个 方法 
在 线程 池 里 是 空 方法 。 





protected void beforeExecute(Thread t, Runnable r) { } 





9.3 本章 小 结 


在 工作 中 我 经 常 友 现 ， 很 多 人 因为 不 了 解 线程 池 的 实现 原理 ， 把 线 
程 池 配置 错误 ， 从 而 导致 了 各 种 问题 。 本 间 介 绍 了 为 什么 要 使 用 线程 
池 、 如 何 使 用 线程 池 和 线程 池 的 使 用 原理 ， 相 信和 阅读 完 本 章 之 后 ， 读 者 
能 更 准确 、 更 有 效 地 使 用 线程 池 。 


第 10 章 ” Executor 框架 


在 Java 中 ， 使 用 线程 来 异步 执行 任务 。Java 线 程 的 创建 与 销毁 需要 
一 定 的 开销 ， 如 果 我 们 为 每 一 个 任务 创建 一 个 新 线程 来 执行 ， 这 些 线程 
的 创建 与 销毁 将 消耗 大 量 的 计算 资源 。 同 时 ， 为 每 一 个 任务 创建 一 个 新 
线程 来 执行 ， 这 种 策略 可 能 会 使 处 于 高 负 和 谷 状 态 的 应 用 最 终 朋 误 。 


Java 的 线程 既是 工作 单元 ， 也 是 执行 机 制 。 从 JDK 5 开始 ， 把 工作 
单元 与 执行 机 制 分 离开 来 。 工 作 单元 包括 Runnable 和 Callable， 而 执行 机 


制 由 Executor 框 架 提供 。 


10.1 Executor 框架 简介 





10.1.1 Executor 框架 的 两 级 调度 模型 


在 HotSpot VM 的 线程 模型 中 ，Java 线 程 (java.lang.Thread〉 被 一 对 
一 映射 为 本 地 操作 系统 线程 。Java 线 程 启动 时 会 创建 一 个 本 地 操作 系统 
线程 ， 当 该 Java 线 程 终止 时 ， 这 个 操作 系统 线程 也 会 被 回收 。 操 作 系统 
会 调度 所 有 线程 并 将 它们 分 配给 可 用 的 CPU。 


在 上 层 ，Java 多 线程 程序 通常 把 应 用 分 解 为 若干 个 任务 ， 然 后 使 用 
用 户 级 的 调度 器 (Executor 框 架 ) 将 这 些 任务 映射 为 固定 数量 的 线程 ; 
在 底层 ， 操 作 系 统 内 核 将 这 些 线 程 映射 到 硬件 处 理 器 上 。 这 种 两 级 调度 
模型 的 示意 图 如 图 10-1 所 示 。 


从 图 中 可 以 看 出 ， 应 用 程序 通过 Executor 框 架 控制 上 层 的 调度 ; 而 
下 层 的 调度 由 操作 系统 内 核 控 制 ， 下 层 的 调度 不 受 应 用 程序 的 控制 。 


10.1.2 ”Executor 框 架 的 结构 与 成 员 


本 文 将 分 两 部 分 来 介绍 Executor: Executor 的 结构 和 Executor 框 架 包 


含 的 成 员 组 件 。 





Executor 框 殊 





OSKernel 





图 10-1 任务 的 两 级 调度 模型 


1.Executor 框 架 的 结构 


Executor 框 架 主要 由 3 大 部 分 组 成 如 下 。 


任务。 包括 被 执行 任务 需要 实现 的 接口 : Runnable 接 口 或 Callable 


接口 。 


` 任务 的 执行 。 包 括 任务 执行 机 制 的 核心 接口 Executor， 以 及 继承 
自 Executot 的 ExecutotSetvice 接 口 。Executot 框 架 有 两 个 关键 类 实现 了 
ExecutotSetvice 接 口 (ThtreadPoolExecutof 和 


ScheduledThteadPoolExecutor) 。 


.异步 计算 的 结果 。 包 括 接 口 Future 和 实现 Future 接 口 的 FutureTask 


Executor 框 架 包含 的 主要 的 类 与 接口 如 图 10-2 所 示 。 
下 面 是 这 些 类 和 接口 的 简介 。 


. 了 Executot 是 一 个 接口 ， 它 是 Executot 框 架 的 基础 ， 它 将 任务 的 提交 


与 任务 的 执行 分 离开 来 。 


.ThteadPoolExecutot 是 线程 池 的 核心 实现 类 ， 用 来 执行 被 提交 的 任 


党 


O 


. ScheduledThteadPoolExecutot 是 一 个 实现 类 ， 可 以 在 给 定 的 延迟 后 


运行 命令 ， 或 者 定期 执行 命令 。ScheduledThreadPoolExecutor 比 Timer 更 


灵活 ， 功 能 更 强大 。 


.Future 接口 和 实现 Futute 接 口 的 FutureTask 类 ， 代 表 异 步 计 算 的 结 


. Runnable 接 口 和 Callable 接 口 的 实现 类 ， 都 可 以 被 


ThreadPoolExecutor 或 Scheduled-ThreadPoolExecutor 执 行 。 


Executor 框 架 的 使 用 示意 图 如 图 10-3 所 示 。 
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图 10-2 ”Executot 框 架 的 类 与 接口 
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图 10-3 ”Executot 框 架 的 使 用 示意 图 


主线 程 首先 要 创建 实现 Runnable 或 者 Callable 接 口 的 任务 对 象 。 工 具 
类 Executors 可 以 把 一 个 Runnable 对 象 封 装 为 一 个 Callable 对 象 
(Executors.callable (Runnable task) 或 Executors.callable (Runnable 


task, Objectresule) ) 。 


然后 可 以 把 Runnable 对 象 直接 交 给 ExecutorService 执 行 
(ExecutorService.execute (Runnable command) ) ; 或 者 也 可 以 把 
Runnable 对 象 或 Callable 对 象 提 交 给 ExecutorService 执 行 〈Executor- 


Service.submit (Runnable task) 或 


ExecutorService.submit (Callable<T>task) ) 。 


如 果 执 行 ExecutorService.Submit 〈... ) ，ExecutorService 将 返回 一 个 
实现 Future 接 口 的 对 象 ( 到 目前 为 止 的 JDK 中 ， 返 回 的 是 FutureTask 对 
象 ) 。 由 于 FutureTask 实 现 了 Runnable， 程 序 员 也 可 以 创建 FutureTask， 
然后 直接 交 给 ExecutorService 执 行 。 


最 后 ， 主 线程 可 以 执行 FutureTask.get(O 方 法 来 等 待 任务 执行 完成 。 
主线 程 也 可 以 执行 FutureTask.cancel (boolean mayInterruptIfRunning) 来 
取消 此 任务 的 执行 


2.Executor 框 架 的 成 员 


本 节 将 介绍 Executor 框 架 的 主要 成 员 : ThreadPoolExecutor、 
ScheduledThreadPoolExecutor、EFuture 接 口 、Runnable 接 口 、Callable 接 


口 和 Executors。 
(1) ThreadPoolExecutor 


ThreadPoolExecutor 通 销 使 用 工厂 类 Executors 来 创建 。Executors 可 
以 创建 3 种 类 型 的 ThreadPoolExecutor: SingleThreadExecutor、 


FixedThreadPool 和 CachedThreadPool。 


下 面 分 别 介 绍 这 3 种 ThreadPoolExecutor。 


1) FixedThreadPool。 下 面 是 Executors 提 供 的 ， 创 建 使 用 固定 线程 
数 的 FixedThreadPool 的 API。 





public static ExecutorService newFixedThreadPool(int nThreads) 
public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactorythreadFe 





FixedThreadPool 适 用 于 为 了 满足 资源 管理 的 需求 ， 而 需要 限制 当前 
线程 数量 的 应 用 场景 ， 它 适用 于 负载 比较 重 的 服务 器 。 


2) SingleThreadExecutor。 下 面 是 Executors 提 供 的 ， 创 建 使 用 单个 
线程 的 SingleThread-Executor 的 API。 





public static ExecutorService newSingleThreadExecutor() 
public static ExecutorService newSingleThreadExecutor(ThreadFactory threadFactory) 





SingleThreadExecutor 适 用 于 需要 保证 顺序 地 执行 各 个 任务 ， 并 上 且 在 
任意 时 间 点 ， 不 会 有 多 个 线程 是 活动 的 应 用 场景 。 





3) CachedThreadPool。 下 面 是 Executors 提 供 的 ， 创 建 一 个 会 根据 需 
要 创建 新 线程 的 CachedThreadPool 的 API。 





public static ExecutorService newCachedThreadPool( ) 
public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) 








CachedThreadPool 是 大 小 无 界 的 线程 池 ， 适 用 于 执行 很 多 的 短期 异 
步 任 务 的 小 程序 ， 或 者 是 负载 较 轻 的 服务 器 。 


(2) ScheduledThreadPoolExecutor 


ScheduledThreadPoolExecutor 通 常 使 用 工厂 类 Executors 来 创建 。 
Executors 可 以 创建 2 种 类 型 的 ScheduledThreadPoolExecutor， 如 下 。 


' ScheduledThreadPoolExecutor。 包含 若干 个 线程 的 


ScheduledThreadPoolExecutor。 


SingleThreadScheduledExecutor。 只 包含 一 个 线程 的 


ScheduledThreadPoolExecutor。 


下 面 分 别 介 绍 这 两 种 ScheduledThreadPoolExecutor。 


下 面 是 工厂 类 Executors 提 供 的 ， 创 建 固定 个 数 线程 的 
ScheduledThreadPoolExecutor 的 API。 





public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) 
public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize,Three 





ScheduledThreadPoolExecutor 适 用 于 需要 多 个 后 台 线 程 执 行 周期 任 
务 ， 同 时 为 了 满足 资源 管理 的 需求 而 需要 限制 后 台 线程 的 数量 的 应 用 场 
景 。 下 面 是 Executors 提 供 的 ， 创 建 单个 线程 的 
SingleThreadScheduledExecutor 的 API。 








public static ScheduledExecutorService newSingleThreadScheduledExecutor() 
public static ScheduledExecutorService newSingleThreadScheduledExecutor 
(ThreadFactory threadFactory) 





SingleThreadScheduledExecutor 适 用 于 需要 单个 后 台 线 程 执行 周期 任 
务 ， 同 时 需要 保证 顺序 地 执行 各 个 任务 的 应 用 场景 。 


(3) Future 接 口 


Future 接 口 和 实现 Future 接 口 的 FutureTask 类 用 来 表示 异步 计算 的 结 
果 。 当 我 们 把 Runnable 接 口 或 Callable 接 口 的 实现 类 提交 (submit) 给 





ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 时 ， 
ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 会 向 我 们 返回 一 个 
FutureTask 对 象 。 下 面 是 对 应 的 API。 





<T> Future<T> submit(Callable<T> task) 
<T> Future<T> submit(Runnable task，T result) 
Future<> submit(Runnable task) 





有 一 点 需要 读者 注意 ， 到 目前 最 新 的 JDK 8 为 止 ，Java 通 过 上 述 API 
返回 的 是 一 个 FutureTask 对 象 。 但 从 API 可 以 看 到 ，Java 仅 仅 保 证 返回 的 
是 一 个 实现 了 Future 接 口 的 对 象 。 在 将 来 的 JDK 实 现 中 ， 返 回 的 可 能 不 


一 定 是 FutureTask。 


(4) Runnable 接 口 和 Callable 接 口 





Runnable 接 口 和 Callable 接 口 的 实现 类 ， 都 可 以 被 
ThreadPoolExecutor 或 Scheduled-ThreadPoolExecutor 执 行 。 它 们 之 间 的 区 
别 是 Runnable 不 会 返回 结果 ， 而 Callable 可 以 返回 结 


除了 可 以 目 己 创建 实现 Callable 接 口 的 对 象 外 ， 还 可 以 使 用 工厂 类 
Executors 来 把 一 个 Runnable 包 装 成 一 个 Callable。 


下 面 是 Executors 提 供 的 ， 把 一 个 Runnable 包 装 成 一 个 Callable 的 


API。 





public static Callable<Object> callable(Runnable task ) // 假设 返回 对 象 Ccallable1 





下 面 是 Executors 提 供 的 ， 把 一 个 Runnable 和 一 个 待 返回 的 结果 包装 
成 一 个 Callable 的 API。 








public static <T> Callable<T> callable(Runnable task, T result) // 假设 返回 对 象 Ce 














前 面 讲 过 ， 当 我 们 把 一 个 Callable 对 象 《〈 比 如 上 面 的 Callable1 或 
Callable2) 提交 给 ThreadPoolExecutor 或 ScheduledThreadPoolExecutor 执 
行 时 ，submit 〈.…) 会 向 我 们 返回 一 个 FutureTask 对 象 。 我 们 可 以 执行 
FutureTask.get(0) 方 法 来 等 待 任务 执行 完成 。 当 任务 成 功 完成 后 
FutureTask.get() 将 返回 该 任务 的 结果 。 例 如 ， 如 果 提 交 的 是 对 象 
Callablel1，FutureTask.get() 方 法 将 返回 null; 如 果 提 交 的 是 对 象 
Callable2，FutureTask.get() 方 法 将 返回 result 对 象 。 


10.2 ThreadPoolExecutor 详 解 


Executor 框 架 最 核心 的 类 是 ThreadPoolExecutor， 它 是 线程 池 的 实现 


类 ， 主 要 由 下 列 4 个 组 件 构成 。 
.cotePool: 核心 线程 池 的 大 小 。 
. maximumPool: 最 大 线程 池 的 大 小 。 
BlockingQueue: 用 来 暂时 保存 任务 的 工作 队列 。 


* RejectedExecutionHandler: 当 ThreadPoolExecutor 已 经 关闭 或 
ThreadPoolExecutor 已 经 饱和 时 (达到 了 最 大 线程 池 大 小 且 工 作 队 列 已 


满 ) ，execute0 方 法 将 要 调用 的 Handlet。 


. 通过 Executot 框 架 的 工具 类 Executofs， 可 以 创建 3 种 类 型 的 


ThteadPoolExecutot。 
FixedThreadPool。 
* SingleThreadExecutoro 
* CachedThreadPool。 


下 面 将 分 别 介 绍 这 3 种 ThreadPoolExecutor。 


10.2.1 FixedThreadPool 详 解 





FixedThreadPool 被 称 为 可 重用 固定 线程 数 的 线程 池 。 下 面 是 
FixedThreadPool 的 源 代 码 实现 。 





public static ExecutorService newFixedThreadPool(int nThreads) { 
return new ThreadPoolExecutor(nThreads, nThreads, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue<RuNnable>( ) ) ; 





FixedThreadPool 的 corePoolSize 和 maximumPoolSize 都 被 设置 为 创建 
FixedThreadPool 时 指定 的 参数 nThreads 。 


当 线 程 池 中 的 线程 数 大 于 corePoolSize 时 ，keepAliveTime 为 多 余 的 
空闲 线程 等 竺 新 任务 的 最 长 时 间 ， 超 过 这 个 时 间 后 多 余 的 线程 将 被 终 
止 。 这 里 把 keepAliveTime 设 置 为 0L， 意 味 着 多 余 的 空闲 线程 会 被 立即 


终止 。 





FixedThreadPool 的 execute(0) 方 法 的 运行 示意 图 如 图 10-4 所 示 。 


LinkedBlockngQueue<Runnable> 







poll() 
take() 


图 10-4 ”FixedThreadPool 的 execute0 的 运行 示意 图 
对 图 10-4 的 说 明 如 下 。 


1) 如 果 当 前 运行 的 线程 数 少 于 corePoolSize， 则 创建 新 线程 来 执行 
任务 。 


2) 在 线程 池 完 成 预 热 之 后 《当前 运行 的 线程 数 等 于 
corePoolSize) ， 将 任务 加 入 LinkedBlockingQueue。 


3) 线程 执行 完 1 中 的 任务 后 ， 会 在 循环 中 反复 从 
LinkedBlockingQueue 获 取 任 务 来 执行 。 


FixedThreadPool 使 用 无 界 队 列 LinkedBlockingQueue 作 为 线程 池 的 工 
作 队 列 ( 队 列 的 容量 为 Integer.MAX_VALUE) 。 使 用 无 界 队列 作为 工 
作 队 列 会 对 线程 池 融 来 如 下 影响 。 


1) 当 线 程 池 中 的 线程 数 达 到 corePoolSize 后 ， 新 任务 将 在 无 界 队 列 
中 等 待 ， 因 此 线程 池 中 的 线程 数 不 会 超过 corePoolSize。 





2) 由 于 1， 使 用 无 界 队 列 时 maximumPoolSize 将 是 一 个 无 效 参数 。 





3) 由 于 1 和 2， 使 用 无 界 队 列 时 keepAliveTime 将 是 一 个 无 效 参 数 。 


4) 由 于 使 用 无 界 队 列 ， 运 行 中 的 FixedThreadPool (未 执行 方法 
shutdown0 或 shutdownNow()) 不 会 拒绝 任务 (不 会 调用 


RejectedExecutionHandler.rejectedExecution 方 法 ) 。 


10.2.2 ”SingleThreadExecutor 评 解 


SingleThreadExecutor 是 使 用 单个 worker 线 程 的 Executor。 下 面 是 


SingleThreadExecutor 的 源 代码 实现 。 





public static ExecutorService newSingleThreadExecutor() { 
return new FinalizableDelegatedExecutorService 
(new ThreadPoolExecutor(1, 1, 
OL, TimeUnit.MILLISECONDS, 
new LinkedBlockingQueue<RunNnnable>())); 





SingleThreadExecutor 的 corePoolSize 和 maximumPoolSize 被 设置 为 
1。 其 他 参数 与 FixedThreadPool 相 同 。SingleThreadExecutor 使 用 无 界 队 
列 LinkedBlockingQueue 作 为 线程 池 的 工作 队列 (队列 的 容量 大 
Integer.MAX_VALUE) 。SingleThreadExecutor 使 用 无 界 队 列 作为 工作 
队列 对 线程 池 带 来 的 影响 与 FixedThreadPool 相 同 ， 这 里 就 不 敬 述 了 。 





SingleThreadExecutor 的 运行 示意 图 如 图 10-5 所 示 。 


LinkedBlockngQueue<Runnabjle> 





图 10-5 SinpgleThteadExecutot 的 execute0 的 运行 示意 图 
对 图 10-5 的 说 明 如 下 。 


1) 如 果 当 前 运行 的 线程 数 少 于 corePoolSize 〈 即 线程 池 中 无 运行 的 
线程 ) ， 则 创建 一 个 新 线程 来 执行 任务 。 


2) 在 线程 池 完 成 预 热 之 后 《当前 线程 池 中 有 一 个 运行 的 线程 ) ， 
将 任务 加 入 Linked-BlockingQueue。 


3) 线程 执行 完 1 中 的 任务 后 ， 会 在 一 个 无 限 循环 中 反复 从 
LinkedBlockingQueue 获 取 任 务 来 执行 。 


10.2.3 ”CachedThreadPool 详 解 





CachedThreadPool 是 一 个 会 根据 需要 创建 新 线程 的 线程 池 。 下 面 是 
创建 CachedThread-Pool 的 源 代 码 。 





public static ExecutorService newCachedThreadPool() { 
return new ThreadPoolExecutor(0, Integer .MAX_VALUE, 
60L, TimeUnit.SECONDS, 
new SynchronousQueue<RUNnable>()); 





CachedThreadPool 的 corePoolSize 被 设置 为 0， 即 corePool 为 空 ; 
maximumPoolSize 被 设置 为 nteger.MAX_VALUE， 即 maximumPool 是 无 
界 的 。 这 里 把 keepAliveTime 设 置 为 60L， 意 味 着 CachedThreadPool 中 的 
空闲 线程 等 待 新 任务 的 最 长 时 间 为 60 秒 ， 空 闲 线程 超过 60 秒 后 将 会 被 终 
es 


FixedThreadPool 和 SingleThreadExecutor 使 用 无 界 队列 
LinkedBlockingQueue 作 为 线程 池 的 工作 队列 。CachedThreadPool 使 用 没 
有 容量 的 SynchronousQueue 作 为 线程 池 的 工作 队列 ， 但 
CachedThreadPool 的 maximumPool 是 无 界 的 。 这 意味 着 ， 如 有 果 主 线程 提 
交 任 务 的 速度 高 于 maximumPool 中 线程 处 理 任务 的 速度 时 ， 
CachedThreadPool 会 不 断 创建 新 线程 。 极 端 情况 下 ，CachedThreadPool 
会 因为 创建 过 多 线程 而 耗 尽 CPU 和 内 存 资 源 。 








CachedThreadPool 的 execute(0) 方 法 的 执行 示意 图 如 图 10-6 所 示 。 


SyirchronousQueue<Runnable> 







poll(keepAliveTime, 


l:offer(Runnable task) TimeUnit. NANOSECONDS) 


execute() 


图 10-6 ”CachedThreadPool 的 execute0 的 运行 示意 图 
对 图 10-6 的 说 明 如 下 。 


1) 首先 执行 SynchronousQueue.offer (Runnable task) 。 如 果 当 前 
maximumPool 中 有 空闲 线程 正在 执行 
SynchronousQueue.poll (keepAliveTime, 
TimeUnit.NANOSECONDS) ， 那 么 主线 程 执行 offer 操 作 与 空 采 线程 执 
行 的 poll 操 作 配 对 成 功 ， 主 线程 把 任务 交 给 空闲 线程 执行 ，execute() 方 
法 执行 完成 否则 执行 下 面 的 步骤 2) 。 











2) 当初 始 maximumPool 为 空 ， 或 者 maximumPool 中 当前 没有 空闲 
线程 时 ， 将 没有 线程 执行 SynchronousQueue.poll (keepAliveTime， 
TimeUnitNANOSECONDS) 。 这 种 情况 下 ， 步 骤 1) 将 失败 。 此 时 
CachedThreadPool 会 创建 一 个 新 线程 执行 任务 ，execute() 方 法 执行 完 
成 。 


3) 在 步骤 2) 中 新 创建 的 线程 将 任务 执行 完 后 ， 会 执行 
SynchronousQueue.poll (keepAliveTime, 
TimeUnitNANOSECONDS ) 。 这 个 poll 操 作 会 让 空闲 线程 最 多 在 
SynchronousQueue 中 每 等 60 秒 钟 。 如 果 60 秒 钟 内 主线 程 提交 了 一 个 新 任 
务 《〈 主 线程 执行 步骤 1) ) ， 那 么 这 个 空闲 线程 将 执行 主线 程 提 交 的 新 
任务 ; 和 否则， 这 个 空闲 线程 将 终止 。 由 于 空 亲 60 秒 的 空闲 线程 会 被 终 
止 ， 因 此 长 时 间 保 持 空闲 的 CachedThreadPool 不 会 使 用 任何 资源 。 


前 面 提 到 过 ，SynchronousQueue 是 一 个 没有 容量 的 阻塞 队列 。 每 个 
插入 操作 必须 等 竺 另 一 个 线程 的 对 应 移 除 操作 ， 反 之 亦 然 。 
CachedThreadPool 使 用 SynchronousQueue， 把 主线 程 提交 的 任务 传递 给 
空 内 线程 执行 。CachedThreadPool 中 任务 传递 的 示意 图 如 图 10-7 所 示 。 


tr 务 给 空闲 线程 





图 10-7” CachedThreadPool 的 任务 传递 示意 图 


10.3 ”ScheduledThreadPoolExecutor 详 解 


ScheduledThreadPoolExecutor 继 承 自 ThreadPoolExecutor。 它 主要 用 
来 在 给 定 的 延迟 之 后 运行 任务 ， 或 者 定期 执行 任务 。 
ScheduledThreadPoolExecutor 的 功能 与 Timer 类 似 ， 但 
ScheduledThreadPoolExecutor 功 能 更 强大 、 更 灵活 。Timer 对 应 的 是 单个 
后 台 线 程 ， 而 ScheduledThreadPoolExecutor 可 以 在 构造 函数 中 指定 多 个 
对 应 的 后 台 线 程 数 。 


10.3.1 ScheduledThreadPoolExecutor 的 运行 机 制 


ScheduledThreadPoolExecutor 的 执行 示意 图 〈 本 文 基 于 JDK 6) 如 图 


10-8 所 示 O 


DelayQueue 是 一 个 无 界 队 列 ， 所 以 ThreadPoolExecutor 的 
maximumPoolSize 在 Scheduled-ThreadPoolExecutor 中 没有 什么 意义 【〈 设 


置 maximumPoolSize 的 大 小 没有 什么 效果 ) 。 
ScheduledThreadPoolExecutor 的 执行 主要 分 为 两 大 部 分 。 


1) 当 调 用 ScheduledThreadPoolExecutor 的 ScheduleAtFixedRate() 方 
法 或 者 scheduleWith-FixedDelay() 方 法 时 ， 会 癌 
ScheduledThreadPoolExecutor 的 DelayQueue 添 加 一 个 实现 了 
RunnableScheduledFutur 接 口 的 ScheduledFutureTask。 


2) 线程 池 中 的 线程 从 DelayQueue 中 获取 ScheduledFutureTask， 然 
后 执行 任务 。 


DelayQueue<RunnableScheduledFutur> 






2:take() 






scheduleAtFixedRate() 
schedule WithFixedDelay() 


图 10-8 ”ScheduledThreadPoolExecutor 的 任务 传递 示意 图 


ScheduledThreadPoolExecutor 为 了 实现 周期 性 的 执行 任务 ， 对 
ThreadPoolExecutor 做 了 如 下 的 修改 。 





. 使 用 DelayQueue 作 为 任务 队列 。 
. 获取 任务 的 方式 不 同 (后 文 会 说 明 ) 。 


. 执行 周期 任务 后 ， 增 加 了 额外 的 处 理 〈 后 文 会 说 明 ) 


10.3.2 ”ScheduledThreadPoolExecutor 的 实现 


前 面 我 们 提 到 过 ，ScheduledThreadPoolExecutor 会 把 待 调 度 的 任务 
(ScheduledFutureTask) 放 到 一 个 DelayQueue 中 。 


ScheduledFutureTask 主 要 包含 3 个 成 员 变 量 ， 如 下 。 
-long 型 成 员 变 量 time， 表 示 这 个 任务 将 要 被 执行 的 具体 时 间 。 
.long 型 成 员 变 量 sequenceNumbet， 表 示 这 个 任务 被 添加 到 
ScheduledThtreadPoolExecutot 中 的 序号 。 
.long 型 成 员 变 量 period， 表 示 任 务 执行 的 间隔 周期 。 


DelayQueue 封 装 了 一 个 PriorityQueue， 这 个 PriorityQueue 会 对 队列 
中 的 Scheduled-FutureTask 进 行 排序 。 排 序 时 ，time 小 的 排 在 前 面 〈 时 间 
早 的 任务 将 被 先 执行 ) 。 如 果 两 个 ScheduledFutureTask 的 time 相 同 ， 就 
比较 sequenceNumber，sequenceNumber 小 的 排 在 前 面 〈 也 就 是 说 ， 如 果 
两 个 任务 的 执行 时 间 相 同 ， 那 么 先 提 交 的 任务 将 被 先 执行 ) 。 


首先 ， 让 我 们 看 看 ScheduledThreadPoolExecutor 中 的 线程 执行 周期 
任务 的 过 程 。 图 10-9 是 ScheduledThreadPoolExecutor 中 的 线程 1 执行 某 个 
周期 任务 的 4 个 步骤 。 


DelayQueue 


PriorityQueue 


ScheduledThread 
PoolExecutor 






线程 1 2: 执 行 任 务 


线程 2 


ScheduledFutureTask 





3: 修 改 time 





线程 3 


图 10-9 ScheduledThtreadPoolExecutot 的 任务 执行 步骤 


下 面 是 对 这 4 个 步骤 的 说 明 。 


1) 线程 1 从 DelayQueue 中 获取 已 到 期 的 
ScheduledFutureTask (DelayQueue.take0) 。 到 期 任务 是 指 
ScheduledFutureTask 的 time 大 于 等 于 当前 时 间 。 


2) 线程 1 执行 这 个 ScheduledFutureTask。 
3) 线程 1 修改 ScheduledFutureTask 的 time 变 量 为 下 次 将 要 被 执行 的 


时 间 。 


4) 线程 1 把 这 个 修改 time 之 后 的 ScheduledFutureTask 放 回 


DelayQueue 中 (Delay-Queue.add()) 。 


接 下 来 ， 让 我 们 看 看 上 面 的 步骤 1) 获取 任务 的 过 程 。 下 面 是 
DelayQueue.take() 方 法 的 源 代码 实现 。 





public E take() throws InterruptedException { 
final ReentrantLock lock = this.lock; 
lock.lockInterruptibly(); 2 
try { 
for (;;) { 
E first = q.peek(); 
if (first == null) { 
available.await( ); // 2.1 
} else { 
long delay = first.getDelay(TimeUnit.NANOSECONDS); 
If (delay > 0) { 


long tl = available.awaitNanos(delay); // 2.2 
} else { 
E x = gq.poll(); Pe Wl 
assert x != null; 
if (gq.size() != 0) 
available.signalAll(); /7 2 32 
return x; 
} 
} 
} 
} finally { 
lock.unlock(); // 3 


} 





图 10-10 是 DelayQueue.take() 的 执行 示意 图 。 


DelayQueue 
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图 10-10 ScheduledThreadPoolExecutot 获 取 任 务 的 过 程 
如 图 所 示 ， 获 取 任 务 分 为 3 大 步骤。 
1) 获取 Lock。 
2) 获取 周期 任务 。 


如 果 PriorityQueue 为 空 ， 当 前 线程 到 Condition 中 等 待 ; 否则 执行 
下 面 的 2.2。 


. 如 果 PtiotityQueue 的 头 元 素 的 time 时 间 比 当前 时 间 大 ， 到 Condition 


中 等 待 到 time 时 间 ; 否则 执行 下 面 的 2.3。 


. 获取 PriorityQueue 的 头 元 素 (2.3.1) ; 如 果 PriorityQueue 不 为 空 ， 
则 唤醒 在 Condition 中 等 待 的 所 有 线程 (2.3.2) 。 


3) 释放 Lock。 


ScheduledTIhreadPoolExecutor 在 一 个 循环 中 执行 步骤 2， 直 到 线程 从 
PriorityQueue 获 取 到 一 个 元 素 之 后 〈 执 行 2.3.1 之 后 ) ， 才 会 退出 无 限 循 
环 〈 结 束 步 骤 2) 。 








最 后 ， 让 我 们 看 看 ScheduledThreadPoolExecutor 中 的 线程 执行 任务 
的 步骤 4， 把 ScheduledFutureTask 放 入 DelayQueue 中 的 过 程 。 下 面 是 
DelayQueue.add0 的 源 代 码 实 现 。 





public boolean offer(E e) { 
final ReentrantLock lock = this.lock; 


lock.1lock(); //1 
try { 
E first = q.peek(); 
q.offer(e); // 2.1 
if (first == null || e.compareTo(first) < 0) 
available.signalAll(); // 2.2 
return true; 
} finally { 
lock.unlock(); // 3 
} 


} 





图 10-11 是 DelayQueue.add0 的 执行 示意 图 。 
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图 10-11 ScheduledThreadPoolExecutot 添 加 任务 的 过 程 
如 图 所 示 ， 添 加 任务 分 为 3 大 步 又 。 
1) 获取 Lock。 
2) 添加 任务 。 
. 向 PriorityQueue 添 加 任务 。 


. 如 果 在 上 面 2.1 中 添加 的 任务 是 PtiotityQueue 的 头 元 素 ， 唤 醒 在 
Condition 中 等 待 的 所 有 线程 。 


3) 释放 Lock。 


10.4 ”FutureTask 详 解 


Future 接 口 和 实现 Future 接 口 的 FutureTask 类 ， 代 表 异 步 计 算 的 结 
果 。 


10.4.1 ”FutureTask 简 介 


FutureTask 除 了 实现 Future 接 口外 ， 还 实现 了 Runnable 接 口 。 因 此 ， 
FutureTask 可 以 交 给 Executor 执 行 ， 也 可 以 由 调用 线程 直接 执行 
(FutureTask.run()) 。 根 据 FutureTask.run0) 方 法 被 执行 的 时 机 ， 
FutureTask 可 以 处 于 下 面 3 种 状态 。 


1) 未 启动 。FutureTask.run() 方 法 还 没有 被 执行 之 前 ，FutureTask 处 
于 未 启动 状态 。 当 创建 一 个 FutureTask， 且 没有 执行 FutureTask.run() 方 
法 之 前 ， 这 个 FutureTask 处 于 未 启动 状态 。 


2) 已 启动 。FutureTask.run(0) 方 法 被 执行 的 过 程 中 ，FutureTask 处 于 
已 局 动 状态 。 


3) 已 完 成 。FutureTask.run() 方 法 执行 完 后 正常 结束 ， 或 被 取消 
(FutureTask.cancel(...) ) ， 或 执行 FutureTask.run() 方 法 时 抛 出 异常 而 


异常 结束 ，FutureTask 处 于 已 完成 状态 。 


图 10-12 是 FutureTask 的 状态 迁移 的 示意 图 。 


线程 


已 完成 






new FutufeTask(...) FutursLaskrun() 


已 启动 


异常 而 结束 





图 10-12 ”FutureTask 的 状态 迁移 示意 图 





当 FutureTask 处 于 未 启动 或 已 启动 状态 时 ， 执 行 FutureTask.getO 方 
法 将 导致 调用 线程 阻塞 ; 当 FutureTask 处 于 已 完成 状态 时 ， 执 行 
FutureTask.get() 方 法 将 导致 调用 线程 立即 返回 结果 或 抛 出 异常 。 








当 FutureTask 处 于 未 启动 状态 时 ， 执 行 FutureTask.cancel() 方 法 将 导 
致 此 任务 永远 不 会 被 执行 ， 当 FutureTask 处 于 已 启动 状态 时 ， 执 行 
FutureTask.cancel (true) 方法 将 以 中 断 执行 此 任务 线程 的 方式 来 试图 停 
止 任务 ， 当 FutureTask 处 于 已 启动 状态 时 ， 执 行 
FutureTask.cancel (false) 方法 将 不 会 对 正在 执行 此 任务 的 线程 产生 影 
响 ( 让 正在 执行 的 任务 运行 完成 ); 当 FutureTask 处 于 己 完 成 状态 时 ， 
执行 FutureTask.cancel(...) 方法 将 返回 false。 











图 10-13 是 get 方 法 和 cancel 方 法 的 执行 示意 图 。 





关 即 返回 结果 或 抛 出 异 销 


get(): 阻塞 


get(: 






getO:| 阻塞 


已 启动 





cancel(true): 中 断 执 行 任务 的 线程 


。 任 和 尔 不 从 让 抽 行 cateel(...): 返回 false 
cancel(…): 任务 不 会 被 执行 cancel(false) :| 不 中 断 执 行 线程 可 


图 10-13 ”FutureTask 的 get 和 cancel 的 执行 示意 图 


10.4.2 ”FutureTask 的 使 用 


可 以 把 FutureTask 交 给 Executor 执 行 ， 也 可 以 通过 
ExecutorService.submit(...) 方法 返回 一 个 FutureTask， 然 后 执行 
FutureTask.get() 方 法 或 FutureTask.cancel(...) 方法 。 除 此 以 外 ， 还 可 以 
单独 使 用 FutureTask。 


当 一 个 线程 需要 等 竺 另 一 个 线程 把 某 个 任务 执行 完 后 它 才 能 继续 执 
行 ， 此 时 可 以 使 用 FutureTask。 假 设 有 多 个 线程 执行 在 干 任务 ， 每 个 任 
务 最 多 只 能 被 执 行 一 次 。 当 多 个 线程 试图 同时 执行 同一 个 任务 时 ， 只 多 
许 一 个 线程 执行 任务 ， 其 他 线程 需要 等 待 这 个 任务 执行 完 后 才能 继续 执 


行 。 下 面 是 对 应 的 示例 代码 。 





private final ConcurrentMap<Object, Future<String>> taskCache = 
new ConcurrentHashMap<Object, Future<String>>(); 
private String executionTask(final String taskName) 
throws ExecutionException, InterruptedException { 
while (true) { 
Future<String> future = taskCache.get(taskName); // 1.1,2.1 
if (future == null) { 
Callable<String> task = new Callable<String>() { 
public String call() throws InterruptedException { 
return taskName; 


了 
FutureTask<String> futureTask = new FutureTask<String>(task)，; 
future = taskCache.putIfAbsent(taskName, futureTask); // 1:3 
If (future == null) { 
future = futureTask; 
futureTask.run(); // 1.. 


} 
} 
try { 
return future.get(); 


} catch (CancellationException e) { 
taskCache.remove(taskName, future); 





上 述 代 码 的 执行 示意 图 如 图 10-14 所 示 。 


ConcurrentHashMap 


taskCache 


ed 1.1:get taskName | |<->| FutureTask 1 
\ Thread 1 | taskName 2 |<> FutureTask 2 





1.2:new 
1.5:get 1.3:putlfAbsent 
2.1:get 
Thread 2 ) 2.2:get 
1.4:run 


图 10-14 代码 的 执行 示意 图 


当 两 个 线程 试图 同时 执行 同一 个 任务 时 ， 如 果 Thread 1 执行 1.3 后 
Thread 2 执行 2.1， 那 么 接 下 来 Thread 2 将 在 2.2 等 待 ， 直 到 Thread 1 执行 
完 1.4 后 Thread 2 才能 从 2.2 (FutureTask.get()) 返回 。 


10.4.3 ”FutureTask 的 实现 


FutureTask 的 实现 基于 AbstractQueuedSynchronizer (以 下 简称 为 
AQS) 。java.util.concurrent 中 的 很 多 可 阻塞 类 (比如 ReentrantLock〉 都 
是 基于 AQS 来 实现 的 。AQS 是 一 个 同步 框架 ， 它 提供 通用 机 制 来 原子 性 
管理 同步 状态 、 阻 塞 和 唤醒 线程 ， 以 及 维护 被 阻塞 线程 的 队列 。JDK 6 
中 AQS 被 广泛 使 用 ， 基 于 AQS 实 现 的 同步 器 包括 : ReentrantLock、 


Semaphore、ReentrantReadWriteLock、CountDownLatch 和 FutureTask。 





每 一 个 基于 AQS 实 现 的 同步 器 都 会 包含 两 种 类 型 的 操作 ， 如 下 。 


` 至 少 一 个 acquire 操 作 。 这 个 操作 阻塞 调用 线程 ， 除 非 /直到 AQS 
的 状态 允许 这 个 线程 继续 执行 。FutureTask 的 acquitre 操 作为 


get0/get (long timeout，TimeUnit unit) 方法 调用 。 


. 至 少 一 个 telease 操 作 。 这 个 操作 改变 AQS 的 状态 ， 改 变 后 的 状态 
可 允许 一 个 或 多 个 阻塞 线程 被 解除 阻塞 。FutureTask 的 telease 操 作 包 括 


tun0 方 法 和 cancel (…) 方法 。 





基于 “复合 优先 于 继承 ”的 原则 ，FutureTask 声 明了 一 个 内 部 私有 的 
继承 于 AQS 的 子 类 Sync， 对 FutureTask 所 有 公有 方法 的 调用 都 会 委托 给 


这 个 内 部 子 类 。 








AQS 被 作为 “模板 方法 模式 ”的 基础 类 提供 给 FutureTask 的 内 部 子 类 
Sync， 这 个 内 部 子 类 只 需要 实现 状态 检查 和 状态 更 新 的 方法 即 可 ， 这 些 
方法 将 控制 FutureTask 的 获取 和 释放 操作 。 具 体 来 说 ，Sync 实 现 了 AQS 
的 tryAcquireShared (int) 方法 和 tryReleaseShared (int) 方法 ，Sync 通 
过 这 两 个 方法 来 检查 和 更 新 同步 状态 。 


FutureTask 的 设计 示意 图 如 图 10-15 所 示 。 


RW 


tryAcquireShared() 


el 





| acquireSharedInterruptibly() | 


运行 任务 的 线程 : - 
runner 线程 等 待 队列 


图 10-15 “FututreTask 的 设计 示意 图 


如 图 所 示 ，Sync 是 FutureTask 的 内 部 私有 类 ， 它 继承 自 AQS。 创 建 
FutureTask 时 会 创建 内 部 私有 的 成 员 对 象 Sync，FutureTask 所 有 的 的 公有 
方法 都 直接 委托 给 了 内 部 私有 的 Sync。 


FutureTask.get() 方 法 会 调用 AQS.acquireSharedInterruptibly (int 
arg) 方法 ， 这 个 方法 的 执行 过 程 如 下 。 


1) 调用 AQS.acquireSharedInterruptibly (int arg) 方法 ， 这 个 方法 首 
先 会 回调 在 子 类 Sync 中 实现 的 tryAcquireShared() 方 法 来 判断 acquire 操 作 
是 否 可 以 成 功 。acquire 操 作 可 以 成 功 的 条 件 为 :state 为 执行 完成 状态 
RAN 或 已 取消 状态 CANCELLED， 且 runner 不 为 null。 


2) 如 果 成 功 则 get0 方 法 立即 返回 。 如 果 和 失败 则 到 线程 等 等 队列 中 
去 等 竺 其 他 线程 执行 release 操 作 。 


3) 当 其 他 线程 执行 release 操 作 〈 比 如 FutureTask.run0 或 
FutureTask.cancel〈...) ) 唤醒 当前 线程 后 ， 当 前 线程 再 次 执行 
tryAcquireShared0 将 返回 正 值 1， 当 前 线程 将 离开 线程 等 待 队列 并 唤醒 
它 的 后 继 线程 〈 这 里 会 产生 级 联 唤醒 的 效果 ， 后 面 会 介绍 ) 。 





4) 最 后 返回 计算 的 结果 或 抛 出 异常 。 
FutureTask.run() 的 执行 过 程 如 下 。 


1) 执行 在 构造 函数 中 指定 的 任务 (Callable.call()) 。 


2) 以 原子 方式 来 更 新 同步 状态 (调用 
AQS.compareAndSetState (int expect，intupdate) ， 设 置 state 为 执行 完 
成 状态 RAN) 。 如 有 果 这 个 原子 操作 成 功 ， 就 设置 代表 计算 结 末 的 变量 
result 的 值 为 Callable.call0 的 返回 值 ， 然 后 调用 AQS.releaseShared (int 


arg) 。 


3) AQS.releaseShared (int arg) 首先 会 回调 在 子 类 Sync 中 实现 的 
tryReleaseShared (arg) 来 执行 release 操 作 ( 设 置 运行 任务 的 线程 runner 
为 null， 然 会 返回 true); AQS.releaseShared (int arg) ， 然 后 唤醒 线程 
等 待 队列 中 的 第 一 个 线程 。 


4) 调用 FutureTask.done()。 





当 执 行 FutureTask.get() 方 法 时 ， 如 果 FutureTask 不 是 处 于 执行 完成 
状态 RAN 或 已 取消 状态 CANCELLED， 当 前 执行 线程 将 到 AQS 的 线程 等 
待 队 列 中 等 待 〈 见 下 图 的 线程 A、B、C 和 D) 。 当 某 个 线程 执行 
FutureTask.run() 方 法 或 FutureTask.cancel(...) 方法 时 ， 会 唤醒 线程 等 待 
队列 的 第 一 个 线程 〈 见 图 10-16 所 示 的 线程 E 唤 醒 线程 A) 。 


线程 等 待 队列 





图 10-16 ”FututeTask 的 级 联 唤醒 示意 图 








假设 开始 时 FutureTask 处 于 未 启动 状态 或 已 启动 状态 ， 等 待 队列 中 
已 经 有 3 个 线程 (A、B 和 C) 在 等 待 。 此 时 ， 线 程 DD 执 行 get() 方 法 将 导致 
线程 D 也 到 等 待 队列 中 去 等 待 。 


当 线 程 E 执 行 run0) 方 法 时 ， 会 唤醒 队列 中 的 第 一 个 线程 A。 线 程 A 被 
唤醒 后 ， 首 先 把 自己 从 队列 中 删除 ， 然 后 唤醒 它 的 后 继 线程 B， 最 后 线 
程 A 从 get() 方 法 返回 。 线 程 B、C 和 DD 重复 A 线程 的 处 理 流程 。 最 终 ， 在 
队列 中 等 待 的 所 有 线程 都 被 级 联 唤 醒 并 从 get(O 方 法 返回 。 


10.5 “本章 小 结 


本 章 介 绍 了 Executor 框 架 的 整体 结构 和 成 员 组 件 。 和 希望 读者 阅读 本 
章 之 后 ， 能 够 对 Executor 框 架 有 一 个 比较 深入 的 理解 ， 同 时 也 希望 本 章 
内 容 有 助 于 读者 更 熟练 地 使 用 Executor 框 架 。 


第 11 音 Java 并 发 编程 实践 








当 你 在 进行 并 发 编程 时 ， 看 着 程序 的 执行 速度 在 自己 的 优化 下 运行 
得 越 来 越 快 ， 你 会 觉得 越 来 越 有 成 束 感 ， 这 束 是 并 发 编程 的 魅力 。 但 与 
此 同时 ， 并 友 编 程 产 生 的 问题 和 风险 可 能 也 会 随 之 而 来 。 本 半 先 介绍 几 
个 并 发 编程 的 实战 案例 ， 然 后 再 介绍 如 何 排查 并 发 编程 造成 的 问题 。 








11.1 生产 者 和 消费 者 模式 


在 并 发 编程 中 使 用 生产 者 和 消费 者 模式 能 够 解决 绝 大 多 数 并 发 问 
题 。 该 模式 通过 平衡 生产 线程 和 消费 线程 的 工作 能 力 来 提高 程序 整体 处 
理 数据 的 速度 。 


在 线程 世界 里 ， 生 产 者 就 是 生产 数据 的 线程 ， 消 费 者 束 是 消费 数据 
的 线程 。 在 多 线程 开发 中 ， 如 果 生 产 者 处 理 速度 很 快 ， 而 消费 者 处 理 速 
度 很 慢 ， 那 么 生产 者 束 必 须 等 竺 消费 者 处 理 完 ， 才 能 继续 生产 数据 。 同 
样 的 道理 ， 如 宋 消费 者 的 处 理 能 力 大 于 生产 者 ， 那 么 消费 者 束 必 须 等 街 
生产 者 。 为 了 解决 这 种 生产 消费 能 力 不 均衡 的 问题 ， 便 有 了 生产 者 和 消 
费 者 模式 。 





什么 是 生产 者 和 消费 者 模式 





生产 者 和 消费 者 模式 是 通过 一 个 容器 来 解决 生产 者 和 消费 者 的 强 耦 
合 问题 。 生 产 者 和 消费 者 彼此 之 间 不 直接 通信 ， 而 是 通过 阻塞 队列 来 进 
行 通信 ， 所 以 生产 者 生产 完 数据 之 后 不 用 等 待 消费 者 处 理 ， 直 接 扔 给 阻 
塞 队列 ， 消 费 者 不 找 生 产 者 要 数据 ， 而 是 直接 从 阻塞 队列 里 取 ， 阻 塞 队 
列 就 相当 于 一 个 缓冲 区 ， 平 衡 了 生产 者 和 消费 者 的 处 理 能 


这 个 阻塞 队列 就 是 用 来 给 生产 者 和 消费 者 解 胡 的 。 纵 观 大 多 数 设 计 
模式 ， 都 会 找 一 个 第 三 者 出 来 进行 解 耦 ， 如 工厂 模式 的 第 三 者 是 工厂 


类 ， 模 板 模式 的 第 三 者 是 模板 类 。 在 学 习 一 些 设计 模式 的 过 程 中 ， 先 找 


到 这 个 模式 的 第 三 者 ， 能 帮助 我 们 快速 熟悉 一 个 设计 模式 。 


11.1.1 生产 者 消费 者 模式 实战 


我 和 同事 一 起 利用 业余 时 间 开 发 的 Yuna 工 具 中 使 用 了 生产 者 和 消费 

者 模式 。 我 先 介 绍 下 Yuna 1 工具， 在 阿里 巴巴 很 多 同事 都 喜欢 通过 邮 
件 分 至 拉 术 文 章 ， 因 为 通过 邮件 分 享 很 方便 ， 大 家 在 网 上 看 到 好 的 技术 
文章 ， 执 行 复 制 - 精 贴 发送 束 完 成 了 一 次 分 诗 ， 但 是 我 发 现 技 术 文 章 
不 能 沉 深 下 来 ， 新 来 的 同事 看 不 到 以 前 分 译 的 技术 文章 ， 大 家 也 很 难 找 
到 以 前 分 至 过 的 技术 文章 。 为 了 解决 这 个 问题 ， 我 们 开 友 了 一 个 Yuna 工 











我 们 申请 了 一 个 专门 用 来 收集 分 享 邮件 的 邮箱 ， 比 如 
share@alibaba.com， 大 家 将 分 享 的 文章 发 送 到 这 个 邮箱 ， 让 大 家 每 次 都 
抄 送 到 这 个 邮箱 表 定 很 麻烦 ， 所 以 我 们 的 做 法 是 将 这 个 邮箱 地 址 放 在 音 
门 邮件 列表 里 ， 所 以 分 享 的 同事 只 需要 和 以 前 一 样 向 整个 部 门 分 享 文 
就 行 。Yuna 工 具 通 过 读 取 邮件 服务 器 里 该 邮箱 的 邮件 ， 把 所 有 分 享 的 邮 
件 下 载 下 来 ， 包 括 邮件 的 附件 、 图 片 和 邮件 回复 。 因 为 我 们 可 能 会 从 这 
个 邮箱 里 下 载 到 一 些 非 分 享 的 文章 ， 所 以 我 们 要 求 分 享 的 邮件 标题 必须 
带 有 一 个 关键 字 ， 比 如 “内 贸 技术 分 享 ”。 下 载 完 邮件 之 后 ， 通 过 
confluence 的 Web Service 接 口 ， 把 文章 插入 到 confluence 里 ， 这 样 新 同事 
就 可 以 在 confluence 里 看 以 前 分 享 过 的 文章 了 ， 并 且 Yuna 工 具 还 可 以 自 
动 把 文章 进行 分 类 和 归档 。 











为 了 快速 上 线 该 功能 ， 当 时 我 们 花 了 3 天 业余 时 间 快 速 开发 了 Yuna 
1.0 版 本 。 在 1.0 版 本 中 并 没有 使 用 生产 者 消费 模式 ， 而 是 使 用 单线 程 来 
处 理 ， 因 为 当时 只 需要 处 理 我 们 一 个 部 门 的 邮件 ， 所 以 单线 程 明显 够 
用 ， 整 个 过 程 是 串 行 执行 的 。 在 一 个 线程 里， 程序 先 抽 取 全 部 的 邮件 ， 
转化 为 文章 对 象 ， 然 后 添加 全 部 的 文章 ， 最 后 删除 抽取 过 的 邮件 。 代 码 
vi 








public void extract() { 
logger .debug(" 开 始 " + getExtractorName() + "。。"); 
// 抽取 邮件 
List<Article> articles = extractEmail(); 
// 添加 文章 
for (Article article : articles) { 
addArticleOrCcomment(article); 











} 

// 清空 邮件 
cleanEmail(); 

logger .debug(" 完 成 " + getExtractorName() + "。。"); 


























Yuna 工 具 在 推广 后 ， 越 来 越 多 的 部 门 使 用 这 个 工具 ， 处 理 的 时 间 越 
来 越 慢 ，Yuna 是 每 隔 5 分 钟 进行 一 次 抽取 的 ， 而 当 邮 件 多 的 时 候 一 次 处 
理 可 能 就 花 了 几 分 钟 ， 于 是 我 在 Yuna 2.0 版 本 里 使 用 了 生产 者 消费 者 模 
式 来 处 理 邮 件 ， 首 先生 产 者 线程 按 一 定 的 规则 去 邮件 系统 里 抽取 邮件 ， 
然后 存放 在 阻塞 队列 里 ， 消 费 者 从 阻塞 队列 里 取出 文章 后 插入 到 
conflunce 里 。 代 码 如 下 。 





public class QuickEmailTowikiExtractor extends AbstractExtractor { 

private ThreadPoolExecutor threadsPool; 

private ArticleBlockingQueue<ExchangeEmailShallowDTO> emailQueue; 

public QuickEmailTowWikiExtractor() { 
emailQueue= new A gst do hh tl 
int corePoolSize = Runtime.getRuntime().availableProcessors() * 2,; 
threadsPool = new ThreadPoolExecutor(corePoolSize, corePoolSize, a TimeUr 


SECONDS ， 
new LinkedBlockingQueue<RuUuNnable>(2000)); 


public void extract() { 
logger .debug(" 开 始 " + getExtractorName() + "。。"); 
long start = System.currentTimeMillis(); 
// 抽取 所 有 邮件 放 到 队列 里 
new ExtractEmailTask().start(); 
// 把 队列 里 的 文章 插入 到 wiki 
insertTowiki(); 
long end = System.currentTimeMillis(); 
double cost = (end - start) / 1000; 
logger .debug(" 完 成 " + getExtractorName() + "花费 时 间 : " + cost +" 秒 ")，; 









































} 
A 
* 把 队列 里 的 文章 插入 到 wiki 
* 
private void insertTowiki() { 
// 登录 wiki, 每 间隔 一 段 时 间 需 要 登录 一 次 
confluenceService.login(RuleFactory.USER_ NAME, RuleFactory .PASSWORD); 
while (true) { 
// 2 秒 内 取 不 到 就 退出 
ExchangeEmailShallowDTO email = emailQueue.poll(2, TimeUnit.SECONDS); 
if (email == null) { 
break; 















































threadsPool.submit(new insertTowikiTask(email)); 


} 


protected List<Article> extractEmail() { 
List<ExchangeEmailShallowDTO> allEmails = getEmailService().queryAllEmails(, 
if (allEmails == null) { 
return null; 


} 

for (ExchangeEmailShallowDTO exchangeEmailShallowDTO : allEmails) { 
emailQueue.offer(exchangeEmailShallowDTO); 

} 


return null; 


} 
/* * 
* 抽取 邮件 任务 





* Qauthor tengfei.fangtf 
*/ 
public class ExtractEmailTask extends Thread { 
public void run() { 
extractEmail( ); 
} 





代码 的 执行 逻辑 是 ， 生 产 者 启动 一 个 线程 把 所 有 邮件 全 部 抽取 到 队 
列 中 ， 消 费 者 启动 CPU*2 个 线程 数 处 理 邮 件 ， 从 之 前 的 单线 程 处 理 邮 件 
变 成 了 现在 的 多 线程 处 理 ， 并 且 抽 取 邮 件 的 线程 不 需要 等 处 理 邮件 的 线 


程 处 理 完 再 抽取 新 邮件 ， 所 以 使 用 了 生产 者 和 消费 者 模式 后 ， 邮 件 的 整 
体 处 理 速度 比 以 前 要 快 了 几 倍 。 


四 “Yuna 取 名 自我 非常 喜欢 的 一 款 RPG 游 戏 《最 终 幻 想 》 中 女 主角 的 名 


> 
O 


11.1.2 多 生产 者 和 多 消费 者 场景 


在 多 核 时 代 ， 多 线程 并 发 处 理 速度 比 单线 程 处 理 速度 更 快 ， 所 以 可 
以 使 用 多 个 线程 来 生产 数据 ， 同 样 可 以 使 用 多 个 消费 线程 来 消费 数据 。 
而 更 复杂 的 情况 是 ， 消 费 者 消费 的 数据 ， 有 可 能 需要 继续 处 理 ， 于 是 消 
费 者 处 理 完 数 据 之 后 ， 它 又 要 作为 生产 者 把 数据 放 在 新 的 队列 里 ， 区 给 
其 他 消费 者 继续 处 理 ， 如 图 11-1 所 示 。 














生产 者 1 


阻塞 队列 1 


阻塞 队列 2 阻塞 队列 3 阻塞 队列 4 


消费 者 3 





图 11-1 多 生产 者 消费 者 模式 


我 们 在 一 个 长 连接 服务 需 中 使 用 了 这 种 模式 ， 生 产 者 1 负责 将 所 有 
客户 端 发 送 的 消息 存放 在 阻塞 队列 1 里 ， 消 费 者 1 从 队列 里 读 消 息 ， 然 后 
通过 消 奶 ID 进行 散 列 得 到 N 个 队列 中 的 一 个 ， 然 后 根据 编写 将 消 恩 存放 
在 到 不 同 的 队列 里 ， 每 个 阻塞 队列 会 分 配 一 个 线程 来 消费 阻塞 队列 里 的 
数据 。 如 果 消 费 者 2 无 法 消费 消息 ， 惑 将 消 轧 再 抛 回 到 阻 豆 队列 1 中 ， 交 





给 其 他 消费 者 处 理 。 


以 下 是 消息 总 队列 的 代码 。 





WA 
* 总 消息 队列 管理 


* 








* Qauthor tengfei.fangtf 





*/ 
public class MsgQueueManager implements IMsgQueuef 
private static final Logger LOGGER 
= LoggerFactory.getLogger(MsgQueueManager .class); 
pS 
* 消息 总 队列 
6 


public final BlockingQueue<Message> messageQueue; 
private MsgQueueManager() { 
messageQueue = new LinkedTransferQueue<Message>(); 


public void put(Message msg) { 
try { 
messageQueue.put(msg); 
} catch (InterruptedException e) { 
Thread.currentThread().interrupt(); 


} 

} 

public Message take() { 
try { 


return messageQueue.take(); 
} catch (InterruptedException e) { 
Thread.currentThread().interrupt(); 








} 
return null; 
} 
} 
局 动 一 个 消 恩 分 发 线 程 。 在 这 个 线程 里 子 队列 自动 去 总 队列 里 获取 
消息 。 
/x 


























* 分 发 消息 ， 负 责 把 消息 从 大 队列 塞 到 小 队列 里 


* Qauthor tengfei.fangtf 
人 
static class DispatchMessageTask implements Runnable { 
@Override 
public void run() { 
BlockingQueue<Message> subQueue; 


for (;;) { 












































// 如 果 没 有 数据 ， 则 阻塞 在 这 里 
Message msg = MsgQueueFactory ,getMessageQueue( ) .take()， 
// 如 果 为 空 ， 则 表示 没有 Session 机 器 连接 上 来 ， 
// 需要 等 待 ， 直 到 有 Session 机 器 连接 上 来 
while ((subQueue = getInstance( ).getSubQueue()) == null) { 
try { 
Thread. sleep(1000); 
} catch (InterruptedException e) { 
Thread.currentThread().interrupt(); 





















































Ee 























} 
} 
// 把 消息 放 到 小 队列 里 
try { 


subQueue.put(msg); 
} catch (InterruptedException e) { 
Thread.currentThread().interrupt(); 


} 





使 用 散 列 (hash〉 算 法 获取 一 个 子 队 列 ， 代 码 如 下 。 





A 
* 均衡 获取 一 个 子 队 列 。 
* 
* @return 
*/ 
public BlockingQueue<Message> getSubQueue() { 
int errorCount = 0; 
for (;;) { 
If (subMsgQueues.isEmpty()) { 
return null; 


int index = (int) (System.nanoTime() % subMsgQueues.size()); 
try { 

return subMsgQueues.get(index); 
} catch (Exception e) { 

// 出 现 错误 表示 ， 在 获取 队列 大 小 之 后 ， 队 列 进行 了 一 次 删除 操作 

LOGGER .error(" 获 取 子 队列 出 现 错误 "，e@); 

If ((++errorCount) < 3) { 

continue; 
} 


























使 用 的 时 候 ， 只 需要 往 总 队列 里 发 消 妃 。 


























// 往 消 息 队 列 里 添加 一 条 消息 
IMsgQueue messageQueue = MsgQueueFactory .getMessageQueue( ) 





Packet msg = Packet,createPacket(Packet64FrameType ， 
TYPE_DATA， "{}".getBytes(), (short) 1); 
messageQueue.put(msg); 


ee | 


11.1.3 ”线程 池 与 生产 消费 者 模式 





Java 中 的 线程 地 类 其 实 就 是 一 种 生产 者 和 消费 者 模式 的 实现 方式 ， 
但 是 我 觉得 其 实现 方式 更 加 高 明 。 生 产 者 把 任务 于 给 线程 池 ， 线 程 池 创 
建 线 程 并 处 理 任务 ， 如 果 将 要 运行 的 任务 数 大 于 线程 池 的 基本 线程 数 就 
把 任务 扔 到 阻塞 队列 里 ， 这 种 做 法 比 只 使 用 一 个 阻塞 队列 来 实现 生产 者 
和 消费 者 模式 显然 要 局 明 很 多 ， 因 为 消费 者 能 够 处 理 直 接 束 处 理 挥 了 ， 
这 样 速度 更 快 ， 而 生产 者 先 存 ， 消 费 者 再 取 这 种 方式 显然 慢 一 些 。 











我 们 的 系统 也 可 以 使 用 线程 池 来 实现 多 生产 者 和 消费 者 模式 。 例 
如 ， 创 建 N 个 不 同 规模 的 Java 线 程 池 来 处 理 不 同性 质 的 任务 ， 比 如 线程 
池 1 将 数据 读 到 内 存 之 后 ， 交 给 线程 池 2 里 的 线程 继续 处 理 压缩 数据 。 线 
程 池 1 主要 处 理 IO 密 集 型 任务 ， 线 程 池 2 主 要 处 理 CPU 密 集 型 任务 。 


本 节 讲 解 了 生产 者 和 消费 者 模式 ， 并 给 出 了 实例 。 读 者 可 以 在 平时 
的 工作 中 思考 一 下 哪些 场景 可 以 使 用 生产 者 消费 者 模式 ， 我 相信 这 种 场 
景 应 该 非常 多 ， 特 别 是 需要 处 理 任 务 时 间 比 较 长 的 场景 ， 比 如 上 传 附 件 
并 处 理 ， 用 户 把 文件 上 传 到 系统 后 ， 系 统 把 文件 丢 到 队列 里 ， 然 后 立刻 
返回 告诉 用 户 上 传 成 功 ， 最 后 消费 者 再 去 队列 里 取出 文件 处 理 。 再 如 ， 
调用 一 个 远程 接口 查询 数据 ， 如 果 远 程 服 务 接口 查询 时 需要 几 十 秒 的 时 
间 ， 那 么 它 可 以 提供 一 个 申请 查询 的 接口 ， 这 个 接口 把 要 申请 查询 任务 








放 数 据 库 中 ， 然 后 该 接口 立刻 返回 。 然 后 服务 器 端 用 线程 轮 询 并 获取 申 
请 任务 进行 处 理 ， 处 理 完 之 后 发 消 妃 给 调用 方 ， 让 调用 方 再 来 调用 另外 
一 个 接口 取 数 据 。 


11.2 ” 线 上 问题 定位 








有 时 候 ， 有 很 多 问题 只 有 在 线 上 或 者 预 发 环境 才能 发 现 ， 而 线 上 又 
不 能 调试 代码 ， 所 以 线 上 问题 定位 束 只 能 看 日 志 、 系 统 状态 和 dump 线 
程 ， 本 市 只 是 简 蛙 地 介绍 一 些 当 用 的 工具 ， 以 帮助 大 家 定位 线 上 问题 。 


1) 在 Linux 命 令 行 下 使 用 TOP 命 令 查 看 低 


村 
可 
让 
呐 
全 
豆 
车 
SS 
4 
让 
dl 


Ts 





top - 22:27:25 Up 463 days, 12:46, 1 user, load average: 11.80, 12.19, 11.79 
Tasks: 113 total, 5 running, 108 sleeping, © stopped, © zombie 

Cpu(s): 62.0%us, 2.8%sy, 0.0%ni, 34.3%id, 0.0%wa, 0.0%hi, 0.7%si, 0.2%st 
Mem: 7680000k total, 7665504k used, 14496k free, 97268k buffers 

Swap: 2096472k total, 14904k used, 2081568k free, 3033060k cached 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 

31177 admin 18 0 5351m 4.0g 49m S 301.4 54.0 935:02.08 java 

31738 admin 15 0 36432 12m 1052 S 8.7 0.2 11:21.05 nginx-proxy 





我 们 的 程序 是 Java 应 用 ， 所 以 只 需要 关注 COMMAND 是 Java 的 性 能 
数据 COMMAND 表 示 启 动 当前 进程 的 命令 ， 在 Java 进 程 这 一 行 里 可 以 
看 到 CPU 利 用 率 是 300%， 不 用 担心 ， 这 个 是 当前 机 器 所 有 核 加 在 一 起 
的 CPU 利用 率 。 











2) 再 使 用 top 的 交互 命令 数字 1 碍 看 每 个 CPU 的 性 能 数据 。 





top - 22:24:50 Up 463 days，12:43，1 user, load average: 12.55, 12.27, 11.73 
Tasks: 110 total, 3 running, 107 sleeping, © stopped, © zombie 

Cpu0 : 72.4%Uus, 3.6%sy, 0.0%ni, 22.7%id, 0.0%wa, 0.0%hi, 0.7%si, QO0.7%st 
Cpu1 : 58.7%Uus, 4.3%sy, 0.0%ni, 34.3%id, 0.0%wa, 0.0%hi, 2.3%si, 0.3%st 
Cpu2 : 53.3%Uus, 2.6%sy, 0.0%ni, 34.1%id, 0.0%wa, QO.0%hi, 9.6%si, 0.3%st 
Cpu3 : 52.7%Uus, 2.7%sy, 0.0%ni, 25.2%id, 0.0%wa, 0.0%hi, 19.5%si, 0.0O%st 

2 0 


0 
0 
0 
Cpu4 : 59.5%us，2.7%Ssy，0,.0%ni，31.2%id，0,.0%wa，0.0%hi，6.6%Ssi，0.0%st 


Mem: 7680000k total, 7663152k used, 16848k free, 98068k buffers 
Swap: 2096472k total, 14904k used, 2081568k free, 3032636k cached 





命令 行 显示 了 CPU4， 说 明 这 是 一 个 5 核 的 虚拟 机 ， 平 均 每 个 CPU 利 
用 率 在 60% 以 上 上。 如果 这 里 显示 CPU 利用 率 100%， 则 很 有 可 能 程序 里 写 
这 些 参数 的 含义 ， 可 以 对 比 表 11-1 来 查看 。 


了 一 个 死 循环 。 


US 

1.0% sy 

0.0% ni 

98.7% id 


0.0% wa 





表 11-1 CPU 参数 含义 


用 户 空 间 占 用 CPU 百分比 

内 核 空 间 占 用 CPU 百分比 

用 户 进程 空间 内 改变 过 优先 级 的 进程 占用 CPU 百分比 
空闲 CPU 百分比 

等 待 输入 /输出 的 CPU 时 间 百 分 比 


3) 使 用 top 的 交互 命令 H 查 看 每 个 线程 的 性 能 信息 。 





PID USER 
31558 admin 
31561 admin 
31626 admin 
31559 admin 
31612 admin 
31555 admin 
31630 admin 
31646 admin 
31653 admin 
31607 admin 


PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 


0 5351m 4.0g9 49m S 12.2 54.0 10:08.31 java 
0 5351m 4.0g 49m R 12.2 54.0 9:45.43 java 
0 5351m 4.0g9 49m S 11.9 54.0 13:50.21 java 
0 5351m 4.0g 49m S 10.9 54.0 5:34.67 java 
0 5351m 4.0g 49m S 10.6 54.0 8:42.77 java 
0 5351m 4.0g9 49m S 10.3 54.0 13:00.55 java 
0 5351m 4.0g 49m R 10.3 54.0 4:00.75 java 
0 5351m 4.0g 49m S 10.3 54.0 3:19.92 java 
0 5351m 4.0g 49m S 10.3 54.0 8:52.90 java 
0 5351m 4.0g 49mS 9.9 54.0 14:37.82 java 





在 这 里 可 能 会 出 现 3 种 情况 


-第 一 种 情况 ， 某 个 线程 CPU 利用 率 一 直 100%， 则 说 明 是 这 个 线程 
有 可 能 有 死 循环 ， 那 么 请 记 住 这 个 PID。 


` 第 二 种 情况 ， 某 个 线程 一 直 在 TOP 10 的 位 置 ， 这 说 明 这 个 线程 可 


. 第 三 种 情况 ，CPU 利 用 率 高 的 几 个 线程 在 不 停 变 化 ， 说 明 并 不 是 
由 某 一 个 线程 导致 CPU 偏 高 。 





如 果 是 第 一 种 情况 ， 也 有 可 能 是 GC 造 成 ， 可 以 用 jstat 命 令 看 一 下 
GC 情况 ， 看 看 是 不 是 因为 持久 代 或 年 老 代 满 了 ， 产 生 Full GC， 导 致 
CPU 利 用 率 持 续 闫 高 ， 命 令 和 回 显 如 下 。 








sudo /opt/java/bin/jstat -gcutil 31177 1000 5 

SO Si1E DO P YGC YGCT FGC FGCT GCT 

0.00 1.27 61.30 55.57 59.98 16040 143.775 30 77.692 221.467 
0.00 1.27 95.77 55.57 59.98 16040 143.775 30 77.692 221.467 
1.37 0.00 33.21 55.57 59.98 16041 143.781 30 77.692 221.474 
1.37 0.00 74.96 55.57 59.98 16041 143.781 30 77.692 221.474 
0.00 1.59 22.14 55.57 59.98 16042 143.789 30 77.692 221.481 








还 可 以 把 线程 dump 下 来 ， 看 看 究竟 是 哪个 线程 、 执 行 什么 代码 造 
成 的 CPU 利用 率 高 。 执 行 以 下 命令 ， 把 线程 dump 到 文件 dump17 里 。 执 
行 如 下 命令 。 





sudo -u admin /opt/taobao/java/bin/jstack 31177 > /home/tengfei.fangtf/dump17 





dump 出 来 内 容 的 类 似 下 面 内 容 。 





"http-0.0.0.0-7001-97" daemon prio=10 tid=0x000000004f6a8000 nid=0x555e in Object ， 
wait() [9x9000000052423000] 
java.1lang.Thread.State: WAITING (on object monitor ) 
at java.lang.Object.wait(Native Method ) 
- Waiting on (a org.apache,.tomcat .util,net.AprEndpoint$worker ) 
at java.lang.Object.wait(Object.java:485) 


at org.apache.tomcat.util.net.AprEndpoint$worker .await(AprEndpoint.java:146< 
- locked (a org.apache.tomcat.util.net.AprEndpoint$worker) 

at org.apache.tomcat.util.net.AprEndpoint$worker .run(AprEndpoint.java:1489) 
at java.lang.Thread.run(Thread.java:662) 





dump 出 来 的 线程 ID (nid〉 是 十 六 进 制 的 ， 而 我 们 用 TOP 命 令 看 到 
的 线程 ID 是 十 进 制 的 ， 所 以 要 用 printf 命 令 转换 一 下 进 制 。 然 后 用 十 六 
进 制 的 ID 去 dump 里 找到 对 应 的 线程 。 





printf "%x\n" 31558 





输出 : 7b46。 


11.3 ”性 能 测试 


因为 要 支持 某 个 业务 ， 有 同事 向 我 们 提出 需求 ， 希 望 系 统 的 某 个 接 
口 能 够 支持 2 万 的 QPS， 因 为 我 们 的 应 用 部 署 在 多 台 机 器 上 ， 要 支持 两 
万 的 QPS， 我 们 必须 先 要 知道 该 接口 在 单机 上 能 支持 多 少 QPS， 如 果 单 
机 能 支持 1 千 QPS， 我 们 需要 20 台 机 器 才能 支持 2 万 的 QPS。 需 要 注意 的 
是 ， 要 文 持 的 2 万 的 QPS 必 须 是 峰值 ， 而 不 能 是 平均 值 ， 比 如 一 天 当中 
有 23 个 小 时 QPS 不 足 1 万 ， 只 有 一 个 小 时 的 QPS 达 到 了 2 万 ， 我 们 的 系统 
也 要 支持 2 万 的 QPS。 








我 们 先进 行 性 能 测试 。 我 们 使 用 公司 同事 开发 的 性 能 测试 工具 进行 
测试 ， 该 工具 的 原理 是 ， 用 户 写 一 个 Java 程 序 同 服务 占 痢 太 起 请 求 ， 这 
个 工具 会 司 动 一 个 线程 池 来 调度 这 些 任 务 ， 可 以 配置 同时 局 动 多 少 个 线 
昌 、 发 起 请 求 次 数 和 任务 间隔 时 长 。 将 这 个 程序 部 署 在 多 台 机 器 上 执 
林 ， 统 计 出 QPS 和 啊 应 时 长 。 我 们 在 10 台 机 器 上 部 普 了 这 个 测试 程序 ， 
每 台 机 器 月 动 了 100 个 线程 进行 测试 ， 压 测 时 长 为 半 小 时 。 注 意 不 能 压 
测 线 上 机 器 ， 我 们 压 测 的 是 开发 服务 絮 。 





人 


~ 





测试 开始 后 ， 首 先 登录 到 服务 占 里 查看 当前 有 多 少 台 机 器 在 压 测 服 
务 促 ， 因 为 程序 的 病 口 是 12200， 所 以 使 用 netstat 命 令 合 询 有 多 少 台 机 器 
连接 到 这 个 端口 上 。 命 令 如 下 。 





$ _ netstat -nat | grep 12200 -c 
10 


通过 这 个 命令 可 以 知道 已 经 有 10 台 机 器 在 压 测 服务 器 。QPS 达 到 了 
1400， 程 序 开 始 报错 获取 不 到 数据 库 连 接 ， 因 为 我 们 的 数据 库 端 口 是 
3306， 用 netstat 命 令 查 看 已 经 使 用 了 多 少 个 数据 库 连 接 。 命 令 如 下 。 


$ netstat -nat | grep 3306 -c 
12 


增加 数据 库 连接 到 20，QPS 没 上 去 ， 但 是 响应 时 长 从 平均 1000 富 秒 
下 降 到 700 毫 秒 ， 使 用 TOP 命 令 观 察 CPU 利 用 率 ， 发 现 已 经 90% 多 了 ， 于 
是 升级 CPU， 将 2 核 升级 成 4 核 ， 和 线 上 的 机 器 保持 一 致 。 再 进行 压 测 ， 
CPU 利用 率 下 去 了 达到 了 75%，QPS 上 升 到 了 1800。 执 行 一 段 时 间 后 响 
应 时 长 稳定 在 200 毫 秒 。 


增加 应 用 服务 器 里 线程 池 的 核心 线程 数 和 最 大 线程 数 到 1024， 通 过 
ps 命令 但 看 下 线程 数 是 否 增长 了 ， 执 行 的 命令 如 下 。 





$ ps -eLf | grep java -c 
1520 
再 次 压 测 ，QPS 并 没有 明显 的 增长 ， 单 机 QPS 稳 定 在 1800 左 右 ， 响 
应 时 长 稳定 在 200 坚 秒 。 


我 在 性 能 测试 之 前 先 优化 了 程序 的 SQL 语 句 。 使 用 了 如 下 命令 统计 
执行 最 慢 的 SQL， 左 边 的 是 执行 时 长 ， 单 位 是 又 秒 ， 右 边 的 是 执行 的 语 


句 ， 可 以 看 到 系统 执行 最 慢 的 SQL 是 queryNews 和 queryNewIds， 优 化 到 
几 十 又 秒 。 





$ grep Y /home/admin/logs/xxx/monitor/dal-rw-monitor.1log |awk -F',' '{print $7$5}' | 
sort -nr|head -20 

1811 queryNews 

1764 queryNews 

1740 queryNews 

1697 queryNews 

679 queryNewIds 








性 能 测试 中 使 用 的 其 他 命令 


< 


1) 查看 网 络 


- 旱 - 
到 量 。 





$ cat /proc/net/dev 

Inter-| Receive | Transmit 

face |bytes packets errs drop fifo frame compressed multicast|bytes packets 
errs drop fifo colls carrier compressed 

10:242953548208 231437133 0 0 0 0 0 0 242953548208 231437133 00G0000 
eth0:153060432504 446365779 0 0G000 0 108596061848 479947142 0 00000 
bond0 :153060432504 446365779 0 0G000 0 108596061848 479947142 0 O00000 





2) 查看 系统 平均 负载 。 





$ cat /proc/loadavg 
0.00 0.04 0.85 1/1266 22459 





3) 查看 系统 内 存 情况 。 





$ cat /proc/meminfo 
MemTotal: 4106756 KB 
MemFree: 71196 kB 
Buffers: 12832 KB 
Cached: 2603332 kB 
SwapCached: 4016 KkB 
Active: 2303768 KB 


Inactive: 1507324 kB 
Active(anon): 996100 kB 
部 分 省 略 























4) 查看 CPU 的 利用 率 。 





cat /proc/stat 

cpu 167301886 6156 331902067 17552830039 8645275 13082 1044952 33931469 0 
cpu0 45406479 1992 75489851 4410199442 7321828 12872 688837 5115394 0 
cpulL 39821071 1247 132648851 4319596686 379255 67 132447 11365141 0 

cpu2 40912727 1705 57947971 4418978718 389539 78 110994 8342835 0 

cpu3 41161608 1211 65815393 4404055191 554651 63 112672 9108097 0 





11.4 异步 任务 池 


Java 中 的 线程 池 设 计 得 非常 巧妙 ， 可 以 高 效 并 发 执行 多 个 任务 ， 但 
是 在 菜 些 场景 下 需要 对 线程 池 进行 扩 展 才能 更 好 地 服务 于 系统 。 例 如 ， 
如 果 一 个 任务 仍 进 线程 池 之 后 ， 运 行 线程 池 的 程序 重启 了， 那么 线程 池 
里 的 任务 就 会 丢失 。 另 外 ， 线 程 池 只 能 处 理 本 机 的 任务 ， 在 集群 环境 下 
不 能 有 效 地 调度 所 有 机 器 的 任务 。 所 以 ， 需 要 结合 线程 池 开 发 一 个 异步 
任务 处 理 池 。 图 11-2 为 异步 任务 池 设 计 图 。 








数据 库 
存储 异步 任务 9 


获取 可 执行 的 

任务 数 ， 更 改 

任务 状态 
任务 隔离 


处 理 完 ， 更 新 
任务 状态 。 





图 11-2 异步 任务 池 设 计 图 


任务 池 的 主要 处 理 流程 是 ， 每 台 机 咒 会 局 动 一 个 任务 池 ， 每 个 任务 
池 里 有 多 个 线程 池 ， 当 攻 台 机 融 将 一 个 任务 交 给 任务 池 后 ， 任 务 池 会 先 


将 这 个 任务 保存 到 数据 中 ， 然 后 某 合 机 器 上 的 任务 池 会 从 数据 库 中 获取 
符 执 行 的 任务 ， 再 执行 这 个 任务 。 


每 个 任务 有 几 种 状态 ， 分 别 是 创建 CNEW) 、 执 行 中 
(EXECUTING) 、RETRY ( 重 试 ) 、 挂 起 (SUSPEND) 、 中 止 
CTEMINER ) 和 执行 完成 (FINISH) 。 


` 创建 : 提交 给 任务 池 之 后 的 状态 。 


. 执行 中 : 任务 池 从 数据 库 中 拿 到 任务 执行 时 的 状态 。 


` 重 试 : 当 执 行 任务 时 出 现 错误 ， 程序 显 式 地 告诉 任务 池 这 个 任务 
需要 重 试 ， 并 设置 下 一 次 执行 时 间 。 

` 挂 起 : 当 一 个 任务 的 执行 依赖 于 其 他 任务 完成 时 ， 可 以 将 这 个 任 
务 挂 起 ， 当 收 到 消息 后 ， 再 开始 执行 。 

. 中 止 : 任务 执行 失败 ， 让 任务 池 停 止 执行 这 个 任务 ， 并 设置 错误 


消息 告诉 调用 端 。 


` 执行 完成 : 任务 执行 结束 。 


任务 池 的 任务 隔离 。 异 步 任务 有 很 多 种 类 型 ， 比 如 抓 取 网 页 任 
务 、 同 步 数据 任务 等 ， 不 同类 型 的 任务 优先 级 不 一 样 ， 但 是 系统 资源 是 
有 限 的 ， 如 果 低 优先 级 的 任务 非常 多 ， 融 优先 级 的 任务 就 可 能 得 不 到 执 


行 ， 所 以 必须 对 任务 进行 隔离 执行 。 使 用 不 同 的 线程 池 处 理 不 同 的 任 
务 ， 或 者 不 同 的 线程 地 处 理 不 同 优先 级 的 任务 ， 如 果 任 务 类 型 非常 少 ， 
建议 用 任务 类 型 来 隔离 ， 如 果 任 务 类 型 非常 多 ， 比 如 几 十 个 ， 建 议 采用 
优先 级 的 方式 来 隔离 。 


任务 池 的 重 试 集 略 。 根 据 不 同 的 任务 类 型 设置 不 同 的 重 试 策略 ， 
有 的 任务 对 实时 性 要 求 高 ， 那 么 每 次 的 重 试 间 隅 惑 会 非常 得， 如果 对 实 
时 性 要 求 不 高 ， 可 以 采用 默认 的 重 试 策 略 ， 重 试 间隔 随 着 次 数 的 增加 ， 
时 间 不 断 增 长 ， 比 如 间隔 几 秒 、 几 分 钟 到 几 小 时 。 每 个 任务 类 型 可 以 设 
置 执行 该 任务 类 型 线程 池 的 最 小 和 最 大 线程 数 、 最 大 重 试 次 数 。 


使 用 任务 池 的 注意 事项 。 任 务必 须 无 状态 : 任务 不 能 在 执行 任务 
的 机 器 中 保存 数据 ， 比 如 某 个 任务 是 处 理 上 传 的 文件 ， 任 务 的 属性 里 有 
文件 的 上 传 路 径 ， 如 果 文 件 上 传 到 机 器 1， 机 器 2 获取 到 了 任务 则 会 处 理 
失败 ， 所 以 上 传 的 文件 必须 存在 其 他 的 集群 里 ， 比 如 OSS 或 SFTP。 





异步 任务 的 属性 。 包 括 任务 名 称 、 下 次 执行 时 间 、 己 执行 次 数 、 
任务 类 型 、 任 务 优先 级 和 执行 时 的 报错 信息 〈 用 于 快速 定位 问题 ) 。 


11.5 本章 小 结 


本 章 介 绍 了 使 用 生产 者 和 消费 者 模式 进行 并 发 编程 、 线 上 问题 排 得 
手段 和 性 能 测试 实战 ， 以 及 寞 步 任 务 池 的 设计 。 并 友 编 程 的 实战 需要 大 
家 平时 多 使 用 和 测试 ， 才 能 在 项 目 中 友 挥 作用 。 


